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DECLARATION UNDER 37 C.F.R. 1,131 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Commissioner: 

We, William W. Smith III. Chartes D. Mentzer, Paul R. McLaughlin and Harland F. Maier 
Jr., do hereby declare and state as follows: 

1. We, William W. Smith III, Charles D. Mentzer, Paul R. McLaughlin and Harland F 
Maier Jr., are co-inventors of the invention described and claimed in the above-referenced 
patent application. We each have reviewed the Office Action mailed October 21 , 2003 in the 
above-referenced application. We have also reviewed the PR Newswire release by Worldwide 
Merchant regarding InterShipper 4.0 ("TEMPE"), and U.S. Patent Application Publication No. 
2002/0022983 (Serial No. 09/873.756) (*Barton n ). Both are relied upon by the Examiner as 
disclosing a computer system for managing shipping of a plurality of parcels by a plurality of 
users using a plurality of carriers recited in Claims 1-8, a method of configuring a plurality of 
server computer devices for managing shipping of a plurality of parcels by a plurality of users 
using a plurality of carriers r cited in Claims 9-19, and a computer program product embodying 
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computer program instructions for execution by a computer for configuring a plurality of server 
computer devices for managing shipping of a plurality of parcels by a plurality of users using a 
plurality of carriers recited in Claims 20-30. This Declaration is filed under 37 C.F.R. §1.131 to 
substantiate our invention of the subject matter claimed in the present application prior to March 
23, 1999, the reported publication date of TEMPE, and therefore prior to April 30, 1999, the 
priority date indicated on the face of Barton. 

2. Prior to March 23, 1999, we invented a multi-service, multi-carrier, Internet- 
enabled server-based shipping system for use by small volume shippers such as small 
businesses and home offices. The concept behind this multi-carrier, multi-service, Internet- 
based shipping system was to provide shipping users ("shippers' 1 ) with a cross-comparison of 
shipment rating, service options, delivery schedules and other services by each of the multiple 
carriers for each of multiple services so that a shipper could compare multiple services offered 
by the multiple carriers and select one service offered by one of the multiple carriers to ship a 
parcel. When this shipping system was first conceived, we worked for Movelt! Software Inc. 
("MoveltP), a company founded in 1997. Later, Movelt! became iShip.com, Inc., which 
eventually merged with Stamps.com Inc. and which is currently a wholly owned subsidiary of 
United Parcel Service ("UPS"). As of the latest date of this Declaration, iShip Inc. and 
Stamps.com are joint owners in common of the subject invention. Through all of the 
aforementioned corporate changes, we continued to develop and test the above-mentioned 
multi-carrier Internet-based shipping system that ultimately led to the filing of the above- 
referenced patent application. 

3. As claimed in Claims 1 through 30 of the present application, as amended, the 
shipping management system, and the methods and computer program products for that 
system, that we invented prior to March 23, 1999, provided a shipping management system 
comprising a plurality of server computer devices. In support of the foregoing statement, we 
hereby submit, attached hereto as Exhibit A, a true and correct copy of pages 13-27 of a file 
copy of a Project Wolverine Design Document; we hereby submit, attached hereto as Exhibit B, 
a true and correct copy of pages 198-228 of a file copy the Project Wolverine Design 
Document. The Project Wolverine Design Document was kept confidential within Movelt!. The 
Project Wolverine Design Document was prepared pursuant to an agreement with College 
Enterprises Inc. ("CEI") whereby Movelt! was to install, operate, support, debug and nurture a 
Beta test version of an early prototype of the above-identified shipping system at a selected 
college campus. The purpose of the Beta test was to experiment with the early stage prototype 
system to determine if It worked, whether it would work over the Internet, and to identify and 
resolve problems and issues with the system. The CEI Beta Test Agreement provided for a 
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50/50 revenue sharing business model of gross profits. A true and correct copy of the CEI Beta 
Test Agreement with Movelt! is attached hereto as Exhibit C. The finalization date of the 
Project Wolverine Design Document was prior to March 23, 1999. 

4. As claimed in Claims 1 through 30 of the present application, as amended, the 
server-based, multi-carrier shipping management system, and the methods and computer 
program products for that system, that we invented prior to March 23, 1999 provided remote 
access by multiple shipping users via the Internet. In support of the foregoing statement, we 
hereby submit, attached hereto as Exhibit D, a true and correct copy of pages 33-34 of the 
Project Wolverine Design Document. 

5. As claimed in one form or another in Claims 3, 7, 8, 13, 17, 24, 27 and 28 of the 
present application, as amended, the remotely accessible, server-based, multi-carrier, Internet- 
enabled shipping management system, and the methods and computer program products for 
that system, that we invented prior to March 23. 1999, provided for obtaining data from at least 
one system database in response to each user input of a request by each particular user to 
ship a parcel. In support of the foregoing statement, we hereby submit, attached hereto as 
Exhibit E, a true and correct file copy of pages 184-188 of the Project Wolverine Design 
Document, and attached hereto as Exhibit F, a true and correct copy of pages 288-298 of the 
Project Wolverine Design Document. 

6. As claimed in Claims 4, 14, 18, 25 and 29 of the present application, as 
amended, the remotely accessible, server-based, multi-carrier, Internet-enabled shipping 
management system, and the methods and computer program products for that system, that 
we invented prior to March 23, 1999, provided for calculation of shipping rates for a plurality of 
carriers. In support of the foregoing statement, we hereby submit, attached hereto as Exhibit 
G. a true and correct file copy of Pages 140-146 of the Project Wolverine Design Document. 

7. As claimed in one form or another in Claims 5, 6, 15, 19, 26, and 30 of the 
present application, as amended, the remotely accessible, server-based, multi-carrier, Internet- 
enabled shipping management system, and the methods and computer program products for 
that system, that we invented prior to March 23, 1999, provided for obtaining carrier tracking 
information from each of a plurality of carrier computer systems accessible over the global 
communications network. In support of the foregoing statement, we hereby submit, attached 
hereto as Exhibit H, a true and correct file copy of Pages 190-196 of the Project Wolverine 
Design Document, and attached hereto as Exhibit I, a true and correct copy of Pages 251-274 
of the Project Wolverine Design Document. 

8. From the time of our invention until the filing date on October 6, 1999 of a first 
provisional application on which priority for the present application is based In part, and 
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thereafter, we continued our effort to refine the operation of the system and resolve problems 
with the system. In support of the foregoing statement, we hereby submit, attached hereto as 
Exhibit J. a true and correct copy of a stream of emails exchanged between us, the inventors, 
and other members of the Movelt!/IShlp development team. 

9. We hereby declare that all statements made herein of our own knowledge are 
true and that all statements made on information and belief are believed to be true; and further 
that the statements were made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 1001, Title 18 of United 
States Code and that such willful false statements may jeopardize the validity of the application 
or any corresponding U.S. patent. 




Harland F. Maier, Jr. 
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3. System Architecture 

This section defines the system architecture for Project Gaucho. This definition includes a high-level 
explanation of the architectural specification for Gaucho and a detailed breakdown of the individual 
software and hardware components that comprise the fully functioning system. 

3.1 Overview 

Essentially, the architecture of the Movelt! technology is organized into three (3) independent layers 
or architectural tiers. The first tier consists of applications that allow users to utilize Movelt! features 
through their web browsers. The second tier contains components that perform general transaction 
management and analysis per the requests of the application tier. The third tier performs data 
management for the system including data storage and retrieval from the data base management 
system (DBMS), the file system, or a queue management facility. Figure 1 below illustrates the 
relationship of these tiers to the user and their web browser. 




Web Browser 




Application 
Tier 




Figure 1. Gaucho Three-Tiered Architecture 



Movelt! supports both Microsoft and Netscape browsers. For the web client users, the Microsoft 
browser must be Internet Explorer 3.x (or more recent) and the Netscape browser must be Navigator 
3.x (or more recent). For Movelt! NOC client and Shipping Station client users the browser must be 
Microsoft Internet Explorer 4.0 (or more recent). 
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The three (3) tiered architecture can be further decomposed into separate components or partitions as 
illustrated in Figure 2 below. The application tier supports individual components that support the web 
client user, NOC operator, or shipping station user. Server components provide a variety of services 
to these clients. The data management tier is. consists of components that manage! data base 
storage, message queue storage and file storage. 



Gaucho Three-Tiered Architecture 



Application 
Tier 



Componont 
Tier 



Data 
Management 
Tier 



Web Applications 



NOC Applications 



Shipping Station 
Applications 




Figure 2. Gaucho Three-Tiered Architecture 
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Figure 3 below provides a detailed illustration of the application tier. Note that a client could utilize 
one or several applications in support of the user's browser activities. 



Application Tier Detail 



Access to Web applications la 
controlled, load balanced, and 
secured by a Proxy Server. 



Shipping Station applications are 
acessed by the end-user and run 
outside of the NOC. Security of 
the machine Is controlled by the 
operating system and by the 
physical layout of the Shipping 
Station at the CEI Pulse Center. 




Figure 3. Application Tier Architecture Detail 
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Figure 4 below provides a detailed illustration of the component tier. Note that a given server 
component may operate within the context of the Microsoft Transaction Server (MTS) or it may be a 
separate (stand alone) executable component. 





Most Server Components run within 
the context of the MTS. MTS provides 
security, transaction, runtime 
performance, and configuration 
management services. Related 
components can be grouped in to 
packages and distributed to other 
machines to handle increasing loads. 



A few Server Components run outside 
of MTS and are standalone 
executables because they need to run 
withing a separate process. These 
generally will be running as NT 
Services. 



Figure 4. Component Tier Architecture Detail 
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Figure 5 below provides a detailed illustration of the data management tier. 
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3.2 Functional Areas And Tiers 

To implement a particular functional requirement, end-user feature, or system service; requires the 
interaction of some or all of the tiers. The sections defines the mapping between Feature and 
Services to tiers. The details of the design presented in this document in alphabetical order. For 
each functional are described below in Table 3-1, there are Applications, and Server Components that 
implement these features. Following that, Table 3-2 defines the mapping between functional areas 



and architectual tiers. 




mnmmmmmmmatmmaamma 






Account Management 


Ctrnnnrfe anrl near monim list inn ftf thotr QPOfltlflt nrpfPr6nC&S 

ouppons ena-user nicinipuiaiiuii ui incii avtuum ^icicichlco. 


Address Book 
Management 


Aiirtu/c ncor6 tn eauo mmmnniv hqaH Qh inn inn address for later use in shiDDino. At a later time 
users can modified their saved addresses. 


a overusing . 


Woh infracfmrfiim A9P rndA pfn that fiiiDDorts dvnamlc and static add placement in and 
around the major Web applications. 


Billing 


Provides functionality to allow reconciliation of carrier bills with Moveltl shipping manifest 
data. 


Claims 


Supports filing a claim against a manifested package. 


History 


Altmue ite Are ♦/* \rla\m ealaMoH nnr+innc nf thAtr chlnnlnfl APtivitV and DerfOfTTl ODeratiOnS On that 
AVllOWS US6IS lO VISW 5ciGUlt?U pUIUUHD UI UlCll ollippiliy oLfiiviij aiiu pen win ■ vpw auwi w v " 

data such as tracking. 


Information 


Web application that provides relatively static information about Movelt! service offerings and 
small parcel snipping, uynamic conieni snouta rocus on rtwj. or uuici u?uMui*ai »uhh u|1 
information, and survey questionnaires. 


Registration 


Application that collect information about a user, validates this data, and in general supports 
the creation of an account with the Wolverine system. 


Reporting 


Provides for generation of standards reports Jhat reflect account activity and shipping history 


Shipping 


Web based small parcel shipping application. 


Tracking 


Web based small parcel tracking application. Implements interfaces that support multi-carrier 
tracking. Tracking in this version in an interactive request 


^Sentfj^ 




Business Rule 


Validates and calculates shipping information. This component is the sole repository of small 
parcel shipping business rules. 


Carrier Connectivity 


Implements the communication link to the carrier back-end systems. Used by other services 
and applications such as Tracking. 


Database Services 


Data storage is provide by the data base either through ADO or ODBC. Database services 
provides a data dictionary object, and access to other shared resources related to the data 
base. 


Drop Site 


Manages drop site information and configuration data. 


Event 


Manages and dispatches messages and events. Reoccurring and one-shot events can be 
scheduled and dispatched from this service 


Import/Export 


Supports file import/export to and from the database. Multiple file formats are allowed. 


Messaging 


Provides store-and-forward messaging services. Used by other services such as carrier 
connectivity and by the Kiosk applications. 


Rating 


Calculates shipping rates based on simple package criterion. 


Security 


Responsible for validating user logins and for storing user privileges. 


Shipping Station 


Supports interfaces that the remote shipping station uses to interact with scales, label printers, 
and report printers. 
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Utility 



Includes classes, and COM interfaces that are used by all other services. For example error 
logging classes, process control, configuration item storage and retrieval. 



Table 3-1. System Features and Services. 
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Web NOC 
Client Apps. 
Apps. 



Shipping 

Station 

Apps. 



Component 
Tier 



Data 
Mangement 
Tier 



Account 
Management 








Address Book 
Management 
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s 




Advertising 




s 




Billing 


s 


s 


✓ 


Claims 


s 


s 




History 


s 


s 




Information 


s 


s 
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Reporting 


s 


s 




Shipping 


s 


s 




Tracking 


s 


s 












Business Rule 




s 


s 
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Connectivity 




s 




Drop Site 




s 


s 


Event 




s 




Import/Export 




s 




Messaging 




s 




Rating 




✓ 


s 


Security 




s 




Shipping Station 


s 


s 




Utility 




s 





Table 3-2. Functional Areas and Applicable Architecture Tiers. 
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3.3 Hardware Architecture 
3.3.1 NOCArchit ctur 

The Network Operations Center (NOC) is comprised of several types of servers configured into a high 
performance, reliable system. Table 6 below defines the six (6) types of servers contained within the 
NOC. 









NOC Web Applicaton 
Server (Configuration "W) 


Dual Processor 2G0mhz Pentium Pro 
256 MB Main Memory 
Dual 100MB Network Cards 
Dual Ultra-Wide SCSI Cards 
Four(4) 4GB Harddrives 
5-10 Minute Full Power UPS 


Microsoft NT Server 4.0 

Microsoft Internet Information Server 4.0 (IIS 

4.0) - Web And FTP Services 

Microsoft Systems Management Server 1.2 

(SMS 1.2) - Network monitoring agent only. 


NOC General Services 
Server (Configuration "G") 


Dual Processor 200mhz Pentium Pro 
256 MB Main Memory 
Dual 100MB Network Cards 
Dual Ultra-Wide SCSI Cards 
Four(4) 4GB Harddrives 
5-10 Minute Full Power UPS 


Microsoft NT Server 4.0 

Microsoft Internet Information Server 4.0 (IIS 

4.0) - Web And FTP Services 

Microsoft Systems Management Server 1 .2 

(SMS 1 .2) - Network monitoring agent only. 

Microsoft Transaction Server 2.0 

Microsoft Message Queue 1.0- Primary or 

Backup Site Controller 


Proxy Server 
(Configuration "P") 


Single Processor 200mhz Pentium Pro 
256 MB Main Memory 
Dual 100MB Network Card 
Ultra-Wide SCSI Cards 
Two(2) 4GB Harddrives 
5-10 Minute Full Power UPS 


Microsoft NT Server 4.0 - The proxy servers 
are the Primary & Secondary WINS servers. 
Also used 

as the Primary and Secondary Domain 

controllers. Network logins from the 

Shipping Stations would 

be controlled by the proxy machines; 

Microsoft Internet Information Server 4.0 (IIS 

4.0) - Proxy Services Only 

Microsoft Proxy Server 2.0 

Microsoft Systems Management Server 1.2 

(SMS 1 .2) - Network monitoring agent only. 


NOC Monitoring And 
Adminstratton Server 
(Configuration "N") 


Single Processor 200mhz Pentium Pro 
128 MB Main Memory 
Single 100MB Network Cards 
Ultra-Wide SCSI Cards 
Two(2) 4GB Harddrives 
5-10 Minute Full Power UPS 


Microsoft NT Server 4.0 
Microsoft Systems Management Server 1 .2 
(SMS 1.2) - Monitoring Application 
SQL Server 6.5 - Storage for network 
monitoring data from SMS, and other 
application logs. 

Microsoft Mananagement Console 4.0 


Database Management 
Server 

(Configuration "D") 


Dual Processor 200mhz Pentium Pro 

1GB Main Memory 

Dual 100MB Network Cards 

Dual Ultra-Wide SCSI Cards 

Four(4) 8GB Harddrives 

5-10 Minute Full Power UPS 

Tape Backup 


Microsoft NT Server 4.0 

Microsoft Systems Management Server 1.2 

(SMS 1.2) - Network monitoring agent only. 

Microsoft SQL Server 6.5 

Microsoft Message Queue 1.0 - This 

machine is the Primary Enterprise Controller 

(PEC) 



Figure 6. NOC Server Configurations 
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3.3.1.1 Alpha-1 (12/1/97 through 1/30/98) 

Figure 7 below illustrates the NOC configuration for the alpha-1 period. This time period lasts 
approximately two (2) months. 
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3.3.1.2 Alpha-2 (2/2/98 through 3/6/98) 

Figur 8 below illustrates the NOC configuration for the alpha-2 period. This time period lasts 
approximately one month. 




Figure 8. NOC Configuration (Alpha-2) 
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3.3.1.3 Alpha-3 (3/9/98 through 4/3/98) 

Figure 9 below, illustrates the NOC configuration for the alpha-3 period. This time period lasts 
approximately one month. 




Figure 9. NOC Configuration (Alpha-3) 
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3.3.1.4 Beta (4/6/98 through 6/26/98) 

Figure 10 below illustrates the NOC configuration for the Beta period. This time period lasts 
approximately three (3) months. 




Figure 10. NOC Configuration (Beta) 



3.3.1.5 Production 1.0 (6/27/98 through 11/29/98) 

The production 1.0 system will be identical to the Beta system defined in the previous section. 

3.3.1.6 Future Production Releases 
TBD 

3.3.2 Shipping Station Architecture 

At each drop-off location there will be one(1) or more shipping stations. The shipping station is a Web 
applications agumented by ActiveX controls to support interaction with the connected hardware. 
Table 3 lists the hardware and software on the two(2) shipping station configurations. These shipping 
stations are connected a Web server at the Movelt! NOC. Each shipping station must have an 
attached scale and a label printer. One of the shipping stations at the drop-off site must also have a 
report printer connected to it. This printer can be a simple dot matrix printer. The purpose of the 
report printer is to print summary manifests that the carriers require when picking up packages. The 
label printer must be able to printer both a receipt label a valid carrier shipping label. Figure 1 1 below 
illustrates the basic components of the shipping station. 
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Standard Shipping Station 


Single Processor 200mhz Pentium 


Microsoft NT Workstation 4.0 


(Configuration "S*) 


32 MB Main Memory 


Norton pcAnywhere 




56K Modem 


Microsoft Internet Explorer 4.x 




IDE or SCSI Controller 






One(1) 2GB Harddrive 






Power Filter 






ELTRON 2044 






Digital Scale Capable of 150lbs. 




run snipping otauon 
(Configuration "F") 


Cinnta Dm/iaeeAr Oflf^mhv Dentil tm 

oingis r roceooDi tuumni rciiuuin 

32 MB Main Memory 

56K'Modem 

IDE or SCSI Controller 

One(1)2GB Harddrive 

Power Filter 

ELTRON 2044 

Digital Scale Capable of 1 50lbs. 
EPSON Compatible Dot-Matrix Printer. 


MirjriQoft NT Workstation 4 0 

Norton pcAnywhere 
Microsoft Internet Explorer 4.x 



Table 3. Shipping Station Configurations 
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Shipping Station At Drop-Off Location 



m 

Report Printer 



I 10.0 Lbs 
1 >- ^ 1 



Label Printer Web Client 



Scale 




Movelt! 

Network Operations Center (NOC) 



Figure 11. Shipping Station Architecture. 
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9. Server Components Overview 

A typical service component is a WIN32 DLL. It may export COM Classes, C++ Classes and/or 
Free Functions. Each component is different. Each detailed design section details what is 
exported to other components to use, the internal implementation details, and what requirements 
it fulfills. 

9.1 Typical Component Design 

Described below is a Design Pattern for a typical server component's COM interfaces. It takes 
into account security requirements, the use of the database for data storage, and usability of 
interfaces from scripting languages. Ail Server Components that use this pattern must support all 
the interfaces, properties, and methods described in this section unless they are noted as 
optional. (As you will see later in the detailed design sections for each component, most designs 
follow this pattern.) If a method does not apply to one of the standard interfaces a component is 
implementing, then the method coded to always return a failure code. 

The pattern is a hierarchy of COM Interfaces. At the root of all the interfaces is the Service 
Interface. Essentially this interface is a secure class factory, through which useful interfaces are 
created. Security is based on a user's rights as defined in there current role. (Roles and security 
are defined in more detail in the Security Services design section.) These interfaces that can be 
created at this level are generally of two(2) types: Administrative Interfaces or Manager 
Interfaces. The Services interface may allow creation of more than one type of Administrative or 
Manager Interfaces. 

The figure below shows the hierarchy of object in a typical Services Component Each of these 
objects is accessed through a well defined interface. Italic characters indicate fields that are 
placeholders that would contain specific names for a specific component. For example, if the 
word "Thing" was replaced with "Package", PackageServices would be the name of highest level 
object. At the lowest level is a business object represented as Thing in this figure. It is through 
this object that most of the business rules of the system are enforced. The following sections 
describe the standard interfaces to each of these object. 



Objects In A Typical Server Component 



T7>//igServices 



TTi/ngAdmin 



rh/rifirCollection 



Thing 



TTwigManager 



TTwigCollection 



Thing 



Figure 15. A Typical Server Component Object Model. 
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9.1.1 The Services Interfac 

All service CoClasses must support IDispatch, lObjectControl, ISupportErrorlnfb, and lUnkown. 
The lObjectControl interface is required specifically to support the Microsoft Transaction Server 
(MTS). One restriction imposed by MTS is that no component is allowed to support aggregation. 
Because some Services support more than one type of business object, more than one Manager 
and Admin Create() methods may be needed. 



WmBmmmMMWMmmmmaaBBBi 



ProgID 


MSI .prefixJThingServlces 


Supported Interfaces 


pre fix J 7M?gServices 




IDispatch 




lObjectControl 




ISupportErrorlnfo 




lUnknown 



Table 5. COM Class prefix_ThingServ\ces. 







None are required. 












Create 7M?gManager() 


Takes a securJUser inteface pointer. It returns a new 
prefix J 7M?gManager interface. This interface is used by 
the general user. The user must be currently logged-on for 
the method to succeed and be in a role allowed for this 
service. A Querylnterface() will fail when trying to retrieve 
the prefix J 77?//igManager interface. 


Create T/?/ngAdmin() 


Takes a securJUser inteface pointer and return a new 
prefixJThingAtimm interface. This interface is for 
administrators only. Contains methods that only NOC 
applications, NOC administrators or technical support can 
use. A Querylnterface() will fail when trying to retrieve the 
prefix JThingAtimin interface. 




'):]■■ - jvi,:: ! ,<'!*■:>-■.-:;- .!-r:*^ ! ; :iy-r-?/*i ■;■ ; : ; pyz ^ v'sSi'- j'sri v";'^ V'i i" " ; V ? =• - •• t - : - '4"! ?'i 1 'l' u ''• ^{HfJlftti 


None are required. 









Table 6. Thing Services Interface. 
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9.1.2 TheManag rlnterfac 

The purpose of the Manager interface is to control storage and retrieval of single or multiple 
business objects. The Manager interface makes no assumptions about where or how these 
business objects are stored. They may reside in an RDBMS t in a disk file, or in memory. 
Methods are subject to security checks against the current securj User privileges. 

Whether or not a filter string is an SQL clause or some other type of filter is dependent on the 
context and storage type. If the Manager supports SQL type clauses, lots of flexibility is possible, 
including changing the sort order. Read the documentation for the particular Manager you are 



accessing. 








None are required. 














ltems() 


Returns a prefixJThingCollection. The number and 
ordering of Things in the collection is determined by the 
passed in filter and the current user. 


Save() 


Takes a prefix JThing as an argument and stores it in data 
storage. The Validate() method of Thing is called prior to 
any attempt to store the object. If the object is currently in 
data storage, it is updated otherwise it is inserted. 


Load() 


Based on an OID retrieves a single Thing object. 


Find() 


Based on a filter string, retrieves the first occurrence of a 
Thing object matching the filter. The returned Thing is 
NULL if nothing matches. 


Count() 


Based on a filter string, retrieves the number of a Thing 
objects matching the filter. The count is set to zero(0) if 
nothing matches. 


Delete() 


Deletes a Thing using the passed in OID. 


Create() 


Creates an empty thing. The properties are filled with all 
the property names and any default values are assigned. 
An OID is generated and the Name property is assigned at 
this time. 


CreateFilterUsingExample() 


Uses the properties of the passed in prefix JThing to build a 
filter string that is returned. Use the filter string on future 
calls to methods that require a filter. 








User 


Returns the securJUser interface used during the creation 
of the prefix_77?//7gManager. 


Table 7. Thing Manager Interface. 
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9.1.3 The Collection Interface 

The ltems() method of the Manager interface returns a pointer to a Collection interface. This is a 
standard collection object as documented in the Microsoft Platform SDK. These objects allow 
retrieval of single items in the collection, or iteration of the entire collection using and enumerator. 
For more information of standard collection objects, see the Microsoft Platform SDK 



documentation. 








ProgID 


MSI. prefix J TtongColIection 






None are required. 
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ltem() 


Returns a 7M?g for the passed in index. Indexes can be 
numbers, strings, or other types. The ltem() method may 
take one or more arguments to indicate the element within 
the collection to return. This method is the default member 
(DibPi DEVALUE:) forine collection ooject. 


:--i2;T.v. .-.St • e, - E t" l -. . . ; ,-■;;■.;=. ft:' i- ->:^ir!. : -: r*? u ■ i ,. :H •-. . «.- :.>■■! 




_NewEnum 


Returns a standard lEnumVARIANT interface. The number 
and ordering of Things that can be enumerated is 
determined by the current filter and the user's security level. 
You may issue another ltems() call to the same Thing 
Manager and this collection remains valid. This method is 
marked "restricted" in the IDL. Note: Within the type library, 
the NewEnum property has a special DISPID: 
DISPID_NEWENUM. 


Count 


The number of items in the collection. For a collection 
stored in the database, this method performs an SQL 
COUNTQ statement. This is a "readonly" property. 



Table 8. Thing Collection Interface. 



9.1.4 The Enumeration Interface 

The _^NewEnum() method in the Collection interface returns the Enumeration interface 
documented in this section. This is a standard COM interface. (For more information on 
enumerators and the lEnumVARIANT interface, see the Microsoft Platform SDK documentation). 
Objects that support lEnumVARIANT can be used very simply by OLE Automation Controllers 
that support "FOR EACH ... NEXT" -like constructs. Behind the scenes the controller calls the 
_NewEnum property from the collection object and then does a Querylnterface to retrieve an 
lEnumVARIANT pointer. IEnumVARIANT::Next is then used to iterate over the collection and 
retrieve individual items in the collection. An example of an automation controller language is 
VBScript. 
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■■■■■■■■■■■rhm 






None are required. 








CIone() 


Copies the current state of the enumeration so you can 

roti irn tn tho nirront olomohf aftpr MQinn Skin A nrRp«iPtn 




cifjn nupr nnp nr mnrp plpmpnte in 3 rnllpntion 


rxeseuj 


Dacatc fho m irront pfprnpnt* tn thp firct plpmPflt in thP 

collection 


Nextf) 


Retrieves one or more elements in a collection, starting 
with the current element 






<None are required> 








<None are required* 





9.1.5 The Business Object Interface 

Every business object shall implement the bizJBusinessObject interface. If the object has 
specific methods then it should implement a separate interface with the name: prefixJThing. 
The purpose of the business object interface is to allow consistent methods for data validation 
and property setting and retrieval. Having one consistent interface on all of the business objects ; 
in the system, allows very general purpose functions to be written that process business objects. 
An example is a presentation function that formate all of a business object's properties into HTML 
for display in a Web browser. This interface is defined in the Business Rule Services section of 
this design document. 

Ah important property of this interface is that every business object has a unique id called on QID 
(Object Identifier). No two(2) new object will every have the same OID. This property of OlDs 
allows quick retrieval of objects from persistent storage, and also fast deletions. 

9.2 Server Component Hierarchy 

The figure below shows the hierarchy of physical dependencies between server component 
packages. At the bottom of the figure is the lowest level package (Utility). All other packages in 
the system are dependent on the facilities provided by this package. There are nine (9) levels in 
all. At the top are packages that implement the highest level features on the system such as 
Claims. Claims for example requires the facilities of Tracking and is therefore dependent upon it. 
The rule that must be followed is that a package may not use services provided by a package 
above it in the hierarchy. 
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Package 



Billing 



Shipping 



Claims 



Tracking Information 



OropSita Advertising Report 



Account . . Massaging 



Address 



Import Export 



Security 



BusinessRule 



Carrier 
Connectivity 



Event 



Utility 



Rating 



Figure 16. Server Component Hierarchy 



9.3 Server Component Detail Designs 

The following sections define in detail each of the server components. 
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9.3.1 Account Services 
9.3.1.1 Overview 

The Account Services provide methods for the administration of all information that is specific to an 
account or to a user. It is with the Account Services that accounts and users are created, altered, and 
deleted. These two entities which Account Services can alter are similar and sometimes contain 
duplicate information, but there are differences between the two. An account must contain at least 
one user while a user need not be connected to an account. The information contained within an 
account includes billing information, sub-accounts, and a list of account users. A user is an entity that 
has shipping information, assigned security roles, and other personal information. When a customer 
creates a new account, they are actually creating a new account and a new user, where the account 
has that newly created user. It is likely that the address contained within the account for billing is 
similar to the shipping address contained within the user entity. The account creator's user becomes 
the account administrator upon creation and can add new users to their account. The amount of 
information a user Is allowed to administer depends on the security privileges they hold for the 
account. 



An account administrator can perform the following abilities: 

• Edit their user information 

• Edit the account's information 

• Create sub-accounts 

• Create new users to be contained in the parent account or sub-accounts 

• Administer security roles for the new users 

Users who belong to the account may or may not have a number of these privileges. Most users start 
with the ability to alter their own information and then the account administrator can grants them more 
privileges. 

The account services were designed to be flexible and easily maintained. The following specific items 
were kept in mind when designing the account services: 

• Accounts can contain sub-accounts 

• Users may belong to several accounts 

• Users need the proper security role before they can administer account information 

• Users have separate roles for separate accounts 



Associated with users are security roles defined by Security Services. These roles are used to 
determine which Account Services interfaces a user may instantiate. Associated with accounts, users 
have separate security roles assigned to them which allow all other applications use to determine 
what actions a user may perform. A user might only hold a SECURJ3ENERAL_USER security role 
when their securJUser interface is queried, but the user's acctJUser interface may show a user as 
having a SECUR_ACCOUNT_ADMIN security role for a particular account. 

9.3.1.2 Structure and Identification 

The table below defines the naming prefix used to define objects within the Account Services and it 
defines the name of the component. 
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Prefix 


acct 


Name 


Account 


Type 


DLL 



Table 1. Account Structure and Identification. 



9.3.1.3 Exported Interfaces 

Exported interfaces are all classes, free functions, & COM interfaces that other packages may need to 
use. In other words, these are the services that this package is providing. Function arguments are 
described but not shown. This is done to make the document more readable and maintainable as the 
design evolves. 

For the Account Services, there are no exported classes or free functions. There are five exported 
COM interfaces for performing various tasks. The main interface, which should be always accessible, 
is the acctJAccountServices interface. With this interface, the other three Account Services' 
interfaces are retrieved. These interfaces include the accounts administration interface, the accounts 
interface, and the interface for accessing user information. . . 

Classes 

There are no exported classes for Account Services. 
Free Functions 

There are no free functions for Account Services. 



COM interfaces 

All COM interfaces to the Account Services are channeled through the same interface. The 
acctJAccountServices interface has methods that are used to create all other account interfaces. 
Th<e ProgID that is stored in the registry and the interfaces that may be retrieved using it are listed in 
the table below. 



BiflBttGiHGS 




iHllil 


wmem 


ProgID 


MSI. acctJAccountServices 


Supported Interfaces 


acctJAccountServices 

IDispatch 

lObjectControl 

ISupportErrorlnfo 

(Unknown 







Table 2. COM Class Account Services 

This section defines the COM interfaces that are exported from the Account Services. Each interface 
is defined in a table that describes its methods and properties. 



Interface acctJAccountServices 

This interface is used to retrieve the other interfaces offered by the Account Services. It is 
instantiated without any need for initialization and will remain present for the life of the web server 
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service. Before any interface is created with acctJAccountServices, a securJUser interface is needs 
to be passed. This security interface is queried to determine the security role a user has and 
depending on the security role found, different interfaces may be retrieved. 











None are required. 








CreateAccountAdmin() 


This method receives a securJUser interface and returns a result 
and a interface for performing administration of all the accounts 
and users. This interface is used to manipulate Account Services' 
preferences. 


CreateAccountManager() 


This method is passed a securJUser interface and it returns a 
result and a interface for accessing the accounts to which the user 
belongs. Depending on security role the user holds, they can use 
methods to alter the account information. 






None are required. 





Table 3. acctJAccountServices Interface Description. 



Interface acctJAccountAdmin 

Only a user who is in the SECUR_ADMIN security role can retrieve this interface, With this interface, 
the administrative user can create, edit, or delete either accounts or users. It is only through this 
interface that accounts and users can truly be deleted. Other interfaces allow you to deactivate an 
account or remove a user from an account but they are not deleted from the database. Even the 
Registration Services must use this interface when it creates a new account for a new customer. 
Basically, all actions which can be performed on a user or account can be achieved through this 
interface. 







Irlflltpi^ 

;; v ^-'v;:^ 


None are required. 








CreateAccountO 


This method creates a new account object and returns a 
acctJAccount interface, (note that the information has not been 
added to the database) If a parent account is specified, the new 
account is created as a sub account. 


DeleteAccount() 


This method is used to delete an account It passed an account's 
object ID and returns a result. 
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ltemAccounts() 


This method creates an acctJAccountCollection interface. The 
number and ordering of Accounts in the collection is determined by 
the defined filter and the current user. 


CountAccounts() 


This method returns the number of all the possible enumerated 
accounts for the filter that was placed on the enumeration. 


SaveAccount() 


This method receives an acctJAccount interface and it updates 
the database to reflect changes in the information. If no account ID 
is specified, a new account ID is created. 


LoadAccount() 


This method receives an account object ID and returns an 
acctJAccount interface for the account. 


FindAccount() 


This method returns an acctJAccount interface based on the 
defined filter and the user who is performing the find. 


AddAccount() 


This method receives two account object IDs and makes one 
account the parent of the other. 


RemoveAccount() 


This method sets the parent of a passed account object ID to be 
NULL 


CreateFilterUsingAccount() 


This method receives an account interface and uses the defined 
properties as a filter for retrieving a collection of accounts. 


CreateUser() 


This method creates a new user object and returns the acctJUser 
interface for it. 


DeleteUser() 


This method is used to delete a user. It is passed a user object ID 
for the user and returns a result. 


ltemUsers() 


This method creates an acctJUserCollection interface. The 
number and ordering of Users in the collection is determined by the 
defined filter and the current user. 


CountUsers() 


This method returns the number of all the possible enumerated 
users for the filter that was placed on the enumeration. 


SaveUser() 


This method receives an acctJUser interface and it updates the 
database to reflect changes in the information. Optionally, a list of 
possible user ID'S are passed. The first unused user ID is used for 
this new user object. 


LoadUser() 


This method receives a user object ID and returns an acctJUser 
interface. 


FindUser() 


This method retrieves an acctJUser interface based on the defined 
filter and the user who is performing the find. 


AddUser() 


This method receives a list of user object IDs and an account 
object ID. The users becomes members of the account. 


RemoveUser() 


This method receives a list of user object IDs and an account 
object ID and it removes the users from the account. If this was 
the last account to which the user belonged, they will be removed 
from use. 


CreateFilterlisihgUserO 


This method receives an user interface and uses the defined items 
as a filter for enumerating users. 
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User() 


Returns the securJUser interface used during the creation of the 
acctJAccountAdmin. 



Table 4. acctJAdminAccounts Interface Description. 



Interface acctJAccountManager 

With the acctJAccountManager interface, the accounts to which a user belongs can be retrieved. If 
the user holds the SECUR_ACCOUNT_ADMIN security role for an account, they can use the 
methods that alter account information and user association. As an account administrator needs, they 
can add new users to an account and remove users who are no longer desired. When a user who 
only holds the SECUR_GENERAL_USER security role for ah account uses this interface, they are 
not able to execute account-altering methods. 








None are required. 








u reateAcco u nn ) 


i nis msinou creates a new aut-uuiu uujt;oi ouu iciuiho q 
acctJAccount interface, (note that the information has not been 
added to the database) A parent account must be specified and 
the new account is created as a sub account. 

Required account security role: SECUR_ACCOUNT_ADMIN 


DeactiyateAccpuntO 


An account cannot be deleted from this interface but this method 
allows it to no longer be accessible by being passed the account 
object ID. 

Required account security role: SECUR_ACCOUNT_ADMiN 


AddAccount() 


This method receives two account object IDs and makes one 
account the parent of the other. 

Required account security role: SECUR„ACCOUNT_ADMIN 


RemoveAccount() 


This method sets the parent of a passed account object ID to be 
NULL 

Required account security role: SECUR_ACCOUNT_ADMIN 


ItemAccountsO 


This method creates an acctJAccountCollection interface. The 
number and ordering of Accounts in the collection is determined by 
the defined filter and the current user. 

Required account security role: SECURj\CCOUNT_ADMIN 


CountAccounts() 


This method returns the number of all the possible enumerated 
accounts for the filter that was placed on the enumeration. 

Required account security role: SECUR_ACCOUNT_ADM!N 
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SaveAccount() 


This method receives an acctJAccount interface and it updates 
the database to reflect changes in the information. If no account ID 
is specified, a new account ID is created. 

Required account security role: SECURJVCCOUNTADMIN 


LoadAccount() 


This method receives an account object ID and returns an 
acctJAccount interface for the account. 


FindAccount() 


This method returns an acctJAccount interface based oh the 
defined filter and the user who is performing the find. 


CreateFiltertlsingAccountO 


This method receives an account interface and uses the defined 
properties as a filter for retrieving a collection of accounts. 






User() 


Returns the securJUser interface used during the creation of the 
acctJAccountManager. 



Table 5. acctJAccountManager Interface Description. 



Interface acctJAccount 

Any user who is a member of an account and holds a security role better than 
SECUR_RESTRICTEDJJSER for the account can retrieve this interface for their account. This 
interface allows for general account information to be retrieved and modified although modifications 
are stored in the database through this interface. Users who obtain this interface and hold a security 
role of SECUR_ACCOUNT_ADMIN for the account can save changes they've made to other users. 











None are required. 










GetPropertiesO 


This method returns a map of the account information contained 
within this object. ... 


PutProperties{) 


This method is passed a map of account information to be 
contained within this object. 


GetPropertyO 


This method is passed a string and it returns a string of the 
corresponding account information that was contained within this 
object. 


PutPropertyO 


This method is passed two strings, one of which is a label and one 
is the matching value to be contained within this object. 


lsPropRequired() 


This method passed a property string and returns a Boolean value 
that tells if the property is required. 


IsPropEdittableO 


This method passed a property string and returns a Boolean value 
that tells if the property can be altered. 


IsPropDirtyQ 


This method passed a property string and returns a Boolean value 
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that tells if the property has been altered with information other 
than that found in the database. 


lsDirty() 


This method returns a Boolean value that tells if the object has 
been altered with information other than that found in the database. 


lsFromStorage() 


This method returns a Boolean value that tells if the object was 
originally retrieved from the database or it was created new. 


lsValid() 


This method returns a Boolean value which informs whether all 
information contained within the object is valid. A map of invalid 
items are returned if any exist 




ThiQ mpthnrl fnrrpc; all thp im/aliH itpmc; to validate if nossibfe 

■ II lid MICUIUU IUI UCO Oil UIO II IVCtllVJ lid HO WJ VailUalC II jJUtf^lulw, 


GetOID() 


This method returns the unique object identifier for the account 
object. 


oreaieuser\; 


T"t"» i r* Araatao ^ na.\kt near nKiaM onH rckflimc tKo nrrf II IcQT 

i nis memoa creaies a new user oojeci ana returns ine acci_iu&er 
interface for it. 

Required account security role: SECUR_ACCOUNT_ADMIN 


DeactivateUser() 


A user cannot be deleted from this interface but this method allows 
it to no longer be accessible by being passed the user object ID. 

Required account security role: SECUR_ACCOUNT_ADMIN 


ltemUsers() 


This method creates an aectJUserCoilection interface. The 
number and ordering of Users in the collection is determined by the 
defined filter and the current user. 

Required account security role: SECUR_ACCOUNT_ADMIN 


CountUsers() 


This method returns the number of all the possible enumerated 
users. 

Required account security role; SECUR^ACCOUNT_ADMIN 


SaveL)ser() 


This method receives an acctJUser interface and it updates the 
database to reflect changes in the information. Optionally, a list of 
possible user ID's are passed. The first unused user ID is used for 
this new user object. 

Required account security role: SECUR_ACCOUNT_ADMIN 


AddUser() 


This method receives a list of user object IDs and an account 
object ID; The users becomes members of the account. 

Required account security role: SECUR_ACCOUNT_ADMIN 


RemoveUser() 


This method receives a Hst of user object IDs and an account 
object ID and it removes the users from the account. If this was 
the last account to which the user belonged, they will be removed 

frnm i i<sp ■ 

II VJI 1 1 UOw. 

Required account security role: SECUR_ACCOUNT_ADMIN 


LoadUser() 


This method receives a user object ID and returns an acctJUser 
interface. 


FindUser() 


This method retrieves an acctJUser interface based on the defined 
filter and the user who is performing the find. 
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CreateFilterUsingUserQ 


This method receives an user interface and uses the defined items 
as a filter for enumerating users. 


if^lpiiliBISiill 






User() 


Returns the securJUser interface used during the creation of the 
acctJAccount; 



Table 6. acctJAccount Interface Description. 



Interface acctJUser 

This interface allows a user to retrieve or update their user specific information. When changes are 
made to a user object, they are not reflected in the database until another interface performs a save 
on the object. When a new user object is created, no user ID is specified for it. Before the user 
object is saved for the first time, a list of possible user IDs is passed and the first unused user ID is 
given to the object ; ^ 




None are required. 








GetProperties() 


This method returns a map of the user information contained within 
this object. 


PutProperties() 


This method is passed a map of user information to be contained 
within this object 


GetPropertyO 


This method is passed a string and it returns a string of the 
corresponding user information that was contained within this 
object. 


PutPropertyO 


Thjs method is passed two strings, one of which is a label and one 
is the matching value to be contained within this object. 


lsPropRequired() 


This method is passed a property string and returns a Boolean 
value that tells if the property is required. 


lsPropEdittable() 


This method passed a property string and returns a Boolean value 
that tells if the property can be altered. 


IsPropDiftyO 


This method passed a property string and returns a Boolean value 
that tells if the property has been altered with information other 
than that found in the database. 


IsDirtyO 


This method returns a Boolean value that tells if the object has 
been altered with information other than that found in the database. 


lsFromStorage() 


This method returns a Boolean value that tells if the object was 
originally retrieved from the database or it was created new. 


lsValid() 


This method returns a Boolean value which informs whether all 
information contained within the object is valid. A map of invalid 



Document: P-DD-97-0910 
Modified: 01/07/98 6:47 PM 



CONFIDENTIAL 



Page 211 



Move It! Software, Inc. . CONFIDENTIAL Project Wolverine Design Document 





items are returned if any exist 


Validate() 


This method forces all the invalid items to validate if possible. 


GetOID() 


This method returns the unique object identifier for the user object 


lsllserlnRole() 


This method returns the security role which the user currently has 
associated with the account which instantiated this interface. 






User() 


Returns the securJUser interface used during the creation of the 
acctJUser. 



Table 7. acctJUser Interface Description. 



Interaction Diagrams 

To better understand the interactions with Account Services and other package and components of 
project Wolverine, interaction diagrams are presented. The diagramis do not depict what is going on 
inside of the Account Services for it is treated here as a black box. 



Creation of New Account Interaction Diagram 

The following figure shows the interactions between a Web Server Application and the Account 
Services' interfaces for creating a new account. The account created is a sub-account to another of 
the user's accounts. The diagram depicts a simple error free scenario. In the first step, the 
acctJAccountServices interface is used to create an interface to an acct J Accounts interface. This 
interface is used to enumerate the accounts that the user can administer. The next scenario begins 
when the user chooses an account under which to create the sub-account. The new account is 
created and filled with default properties which are used to fill the form which the user is offered. 
Finally, after the user fills in the form, the properties are placed within the account, the account is 
validated, and the account is stored into the database. 
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Web Server 



acrtJAccountServices : 
a cctTAcooun {Services 





acta (Accounts: 




acct (Account : 




Database 




acct TAccounts 




acct TAccount 







Screen One: 
User Log On 



1 : CreateAccountManager ( ) 2 . (nslantjat0 



Screen Two: 

User chooses an account' 
and chooses to create a 
sub-account . 



Screen Three: v 
User enters properties T 
and submits Information 



Screen Four 
User is told that the 
action was successful 
and the new account ID 




After user logs on, 
they receive a list of 
the accounts to 
which they belong. 



Instantiate a new 
account and set 
default properties 



Data is validated and 
then saved in the 
database at which 
time the account ID is 



Figure 1. Creation of New Account Interaction Diagram 



Addition of New User Interaction Diagram 

The following figure shows the interactions between a Web Server Application and the Account 
Services' interfaces for creating a new user in an account. The user created becomes a member of 
one of the accounts that the account administrator can administrate. The diagram depicts a simple 
error free scenario. In the first step, the acctJAccountServices interface is used to create an 
interface to an acctJAccounts interface. This interface is used to enumerate the accounts that the 
user can administer. The next scenario begins when the user chooses an account under which to 
create the new user. A new user is created and filled with default properties which are used to fill the 
form which the administrator is offered. Finally, after the administrator fills in the form, the properties 
are placed within the new user, the user is validated, and the user is stored into the database. 
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Screen On©: 
User Log On 



Screen Two: 
User chooses an 
account 



Screen Three: Y 
User chooses to add 
anew user 



Screen Four 

Admin user is i 

presented with a form I 

to fill out for user j 



Screen Five: 

Admin user is told the I 
transaction was successful 
and the new user's ID | 



They receive a list of 
the accounts to 
which they belong. 




Figure 9.3.1-2. Addition of New User Interaction Diagram 



Messages 

The table below defines messages that either <Gadget> Services publishes or subscribes to. For 
more information on messages, see the Event Services design section in this document. 




< PKG IGADGET.PERFORMING INITIALIZATION > 



<Message sent at the start of 
initializations 
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111 






<None are required.> 




m 






< PKG_IGADGET.DB_CONNECTION_FAILURE > 


<Couldn't connect to the database during 
the initialization process> 






< PKG IGADGET.DO SOMETHING> 


<Performs DoSomething() in response to 
the job request messages 



Table 8. Publish and Subscribe Messages Supported by <Package Name> Services. 



9.3.1.4 Implementation Details 

Under each of the external interfaces is a supporting class. The functionality of the methods provided 
by each of the classes is described by the corresponding COM interfaces listed above. 

Ciasses 

Class Diagrams 

The classes used to implement the Account Services have few interactions. They are tied together 
because some of the classes are used to create other class objects. For instance, the 
acct_TAccountServices class has a method for creating an acctJTAdminAccounts object. Although 
the class object is created by acctJTAccountServices, the responsibility for freeing the object lies 
elsewhere. A number of utility classes are used by Account Services to perform various canned 
functionality. A few are shown as examples in the below diagram. 
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acct TAccountServices 



+CreateAdminAccounts( ) 
^CreateAccountManager( ) 



acct TAdminAccounts 



♦CreateAccount( ) 
♦OeleteAccount( ) 
♦EnumAccounts( ) 
^CountEnumAccounts{ ) 
4saveAccounts( ) 
^FindAccount( ) 
<j>AddAccount( ) 
^RemoveAccountf ) 
*GetAccountFPter() 
♦PutAccountFiller() 
♦GetAccountSortBy{ ) 
♦PutAccountSortBy( ) 
%PutFlltorUslngAccount( ) 
%CreateUs6r( ) 
^DeleteUser( ) 
^EnumUsers( ) 
4tCountEnumllsers( ) 
*SaveUser( ) 
♦FindUser() 
*AddUser( ) 
^RemoveUser( ) 
♦GetUserFilterO 
♦PutUserFilter( ) 
♦GetUserSortBy( ) 
♦PutUserSortByO 
VutRIterUsingUser() 



/ 



/ 



/ 



/ 



utll TEmail 



*SendEmat1( ) 



/ 



util_TStateZip 



%Validate( ) 



N 



acct TUser 



♦GetProperties( ) 
♦PutProperties( ) 
^GetPropertyt ) 
4PutProperty( ) 
♦lsPropRequired( ) 
*JsPropEdittable() 
*tsPropDirty( ) 
%lsDirty() 
<MsFromStorage( ) 
♦lsValid() 
♦Va!idate() 
*3et01D() 



acct TAccount 



V3etProperties( ) 
♦PutProperties( ) 
%GetProperty( ) 
♦PutProperty( ) 
♦lsPropRequired( ) 
♦1sPropEdittable() 
♦lsPropDirty( ) 
*lsDlrty() 
♦lsFromStorage( ) 
♦lsVa!id( ) 
*Val[date() 
^GetOID() 
^CreateUser( ) 
*EnumUsers( ) 
♦CountEnumUsers( ) 
%SaveUser( ) 
♦FindUsert) 
VVddUsert) 
♦RemoveUser( ) 
4GetUserFilter( ) 
%PutUserFilter( } 
♦GetUserSortByO 
♦PutUserSortByO 
VutFilterUsingUser( ) 



/ 



4 



acct TAccounts 



4CreateAccount( ) 
♦DeactivateAccount( ) 
♦AdtfAocount( ) 
^RemoveAccount( ) 
V5aveAccount( ) 
*FindAccount( ) 
*EnumAccounts( ) 
<iCountEnumAccounts( ) 
♦GetFilter{)- 
♦PutFiiter() 
+GetSortBy( ) 
♦PutSortBy( ) 
%PutFilterUsingAccount( ) 



Figure 3. Class Hierarchy Diagram for Account Services. 
Free Functions 

There are no free functions required for the Account Services. 
interaction Diagrams 

There are no interaction diagrams required for the Account Services. 



9.3.1.5 External Dependencies 

The Account Services relies on a number of database tables to contain the information about 
accounts and users. The associations between users and accounts are contained in the database but 
the rules applied to their association are mainly stored within the Account Services' classes. 

The table below lists dependencies that this package has on other components and database tables. 





MUD 












Database Table 




vw_Account 
vwJJser 


Account Information 
User Information 
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vw_AccountAndUser 


Users belong to Accounts 


Utility Package Classes 


utiI_TEmail 
util_TStateZip 


Sending email 

Validation of state and zip code 


COM Object 


(Dictionary 


Microsoft dictionary 




IList 


Microsoft list 


DLL 


MFC42.DLL 


Microsoft MFC support DLL 


Static Library 


ATL 


Active X Template Library > 



Table 9. Account Services External Dependencies 

9.3.1.6 Requirements Traceability Matrix 

< The table should list all the individual line item requirements met by the application. The 
Class/Function/Interface column should list the names of these objects.> 

The table below traces requirements from the Server functional requirements to components of the < 
Package Name > service. 



<1.1.1> 



=:pkg_IGadget> 



<Really, it does fulfill the 
requirements 



Table 10. <Package Name> Services Requirements Traceability Matrix 
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9.3.2 Address Book Services 

9.3.2.1 Overview 

Address Book Services provides users with the capabilities to maintain their own recipient 
address in the database. 

The Address Book Services package is designed to allow the user to: 

• Add a new recipient address to the database. 

• Update an existing recipient address in the database. 

• Delete an existing recipient address from the database. 

• Retrieve recipient addresses from the database. 

9.3.2.2 Structure and Identification 

The table below defines the naming prefix used to define objects within the Address Book 
Services component and it defines the name of the component. 



ran 






ma 


Prefix 


addr 


Name 


Address 


Type 


DLL 



Table 11. Address Book Structure and Identification. 



9.3.2.3 Exported Interfaces 

Exported interfaces are all classes, free functions, & COM interfaces that other packages may 
need to use. In other words, these are the services that this package is providing. Function 
arguments are described but not shown. This is done to make the document more readable and 
maintainable as the design evolves. 

9.3.2.3.1 Classes 

None are required. 

9.3.2.3.2 Free Functions 

None are required. 
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9.3.2.3.3 COM Interfaces 

This section defines the COM interfaces that are exported from the Address Book Services. Each 
interface is defined in a table that describes its methods and properties. 



COM Class AddressBookServices 









Pf ill 




ProgID 


MSI.addr_AddressBookServices 


Supported Interfaces 




addrJAddressBookServices 

IDispatch 

lObjectControi 

ISupportErrorlnfo 

1 Unknown 







Interface addrJAddressBookServices 

This main interface will create the address book interface manager addrJAddressManager. 





^^^^^^^^^^^^^^ 








ProgID 


MSI.addrJAddressBookServices 








Activate() 


Performs context-specific initialization. 


Deactivate() 


Releases the object's ObjectContext reference and does 
other context-specific cleanup. 








CreateAddressManager() 


Takes a securJUser inteface pointer and returns a new 
addrJAddressManager interface. This interface is used by 
the general user. The user must be currently logged-on for 
the method to succeed and have the correct privilege. 


CreateAddressAdminO 


Takes a securJUser inteface pointer and return a new 
addrJAddressAdmin interface. This interface is for 
administrators only. Contains methods that only NOC 
applications, NOC administrators or technical support can 
use. A Querylnterface() will fail when trying to retrieve the 
addrJAddressAdmin interface. 






:~- • •■• j ! • *: 'v : :-C.-*r.'\i < 


None are required. 
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i i ") 

Table 12. addrJAddressBookServices Interface Description. 



) 
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Interface addrJAddressManager 

The Manager interface looks like a standard collection interface to scripting languages. Methods 
are subject to security checks against the current securJUser privileges. 







ProgID 


MSI.addrJAddressManager 






None are required. 








iiiiiiiiaiiiiiiii 




ltems() 


Retuns an addrJAddressCollection. The number and 
ordering of addrJAddress in the collection is determined by 
the current filter, sort by properties, and the user's security 
level. 


Save() 


Takes an addrJAddress as an argument and stores the 
address book data in database. The Validate() method of 
addrJAddress is called prior to any attempt to store the 
ODjecL it in 6 oDjeci is currently in uaiaudoc, u io ujjuaieu 
otherwise it is inserted. 


Find() 


Based on an OID creates and retrieves a single 
addrJAddress. 


Delete() 


Deletes an addrjaaaress using tne passea in uiu. 


Create() 


Creates an empty addrJAddress. I ne properties are nnea 
with all the property names and any default values are 
assigned. An OID is also generated and assigned at this 
time. 


PutrilterUsmgcxample() 


Uses the properties ot tne passea in aaa rj Auaress to uuna 
an SQL where clause filter. The Filter property is then set. 
Effects the results of the next call to retrieve a collection. 






GetFilter() 


Returns the current filter string. 


PutFilter() 


Sets the filter string. The string is an SQL where clause 
minus the "WHERE". Effects the results of the next call to 
retrieve a collection. 


GetSortBy() 


Returns the current sort by string. 


PutSortBy() 


Set the order by string. The string is an SQL order by 
clause minus the "ORDER Br'. A default order by shall be 
set when addrJAddress interface is created. Effects the 
results of the next call to retrieve a collection. 
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GetUser() 


Returns the securJUser interface used during the creation 




of the addrJAddressManager. 



Table 13. addrJAddressManager Interface Description. 
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Interface addrJAddr ssCollectlon 

This interface is a collection of address books. It supports three read-only properties, each of 
which has a single accessor function. 




mammmmmmmmm 






ProgID 


MSI.addrJAddressCollection 






None are required. 












ltem() 


Returns an addrJAddress for the passed in index. 






_NewEnum() 


Returns an lEnumVARIANT interface. The number and 
ordering of addrJAddress that can be enumerated is 
determined by the current filter, sort by properties, and the 
user's security level. If you are enumerating things and the 
filter is changed, and error, will occur when the next thing is 
retrieved. This method is marked "restricted" in the IDL. 


Count() 


The number of items in the collection. 



Table 14. addrJAddressCollection Interface Description. 
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Interface addrJAddress 



This interface allows Web server to interrogate the address book properties. 





MM 










ProgID 


MSI.addrJAddress 






None are required. 












'ti/ni'i' J 1 * !•■• * 'i'l * * - ; v r! ill r ! H' l>' ! 't i>! J "''j*£ j'r"' ! Li i ?-!tj- I's ftfyliit: 3i jl!i !tf'0.ii!>uL>!wt-aikVit!^ i"vJ 


ValidateO 


Returns a boolean value indicating whether some property 
was found to be invalid. If one or more properties are 
invalid an additional argument populates a Map with 
property names and error text. Only returns a bad 
HRESULT if a fatal error has occurred. This method is 
responsible for inter-field validation. It is assumed that the 
properties are valid 


oetProperties() 


Returns an IMap interface of properties. 


PutProperties() 


Takes an IMap interface. Properties are validated for data 
dictionary violations but not for inter-property validation. 
The OID cannot be changed using this method. 


GetPropertyO 


Returns the value of a single property as a VARIANT- The 
property is indexed by a key. 


PutProperty() 


oet tne value or a single property. Kequires a Key ana 
VARIANT property data. The property is validated for data 
dictionary violations. The OID cannot be changed using 
this method. 


GetPropValues() 


Takes a property name and returns a VARIANT array of 
allowed values. Used for example to populate a list box. 


lsPropRequired() 


Takes a property name and returns a boolean value 
indicating whether the property is required to have a value. 


lsPropEditable() 


Takes a property name and returns a boolean value 
indicating whether the property is available for editting, 
otherwise, the property is read-only. 


IsPropDirtyO 


Takes a property name and returns a boolean value 
indicating whether the property has been modified since the 
last successful validation. 


lsDirty() 


Returns a boolean value indicating whether any property 
has been modified since the object was created. 


lsValid() 


Returns a boolean value indicating whether a successful 
validation had been performed since, the last property 



Document: P-DD-97-0910 CONFIDENTIAL Page 224 

Modified: 01/07/98 6:47 PM 



Movelt! Software, Inc. 



CONFIDENTIAL 



Project Wolverine Design Document 





change. Does not call the Validate() method. 


IsFromStorageQ 


Returns a boolean value indicating whether the object was 
originally retrieved from data storage. This is used when 
saving an object back into storage to determine if an Insert 
or Update needs to be performed; 






GetOID() 


Retrieves the OID of the current object. 



Table 15. addrJAddress Interface Description 
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9.3.2.3.4 Interaction Diagrams 

To better understand the interactions with Address Book Services and other package and 
components of project Wolverine, interaction diagrams are presented: Each diagram depicts a 
scenario showing one or more components interacting. The diagrams do not depict what is going 
on inside of the Address Book Services. It is treated here as a black box. 



Figure 4. shows how the interaction between a Web Server Application and the Address Book 
Services interfaces. The diagram depicts a simple error free scenario. It demonstrates how a new 
recipient address is created and insert into database. 



Web Server 
Application 



addrJAddress 
BookServices 



addrJAddress 
BookManager 



addr lAddress 



i1: CreateAddressBookManagerQ 



2: Createi 



3? 

_ u 



i 

|3: ValidateO 



4: SaveQ 



Figure 4. Add a New Recipient Address. 
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Figure 5. demonstrates how an existing recipient address is deleted from database. 



Web Server 
Application 



addrJAddress 
BookServices 



addrJAddress 
BookManager 



i1: CreateAddressBookManagerO | 





I 



2: Create(r 



|3:ValidateO 



4: DeleteQ 



addr (Address 



"0 



Figure 5. Delete an Existing Recipient Address. 
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Figure 6. demonstrates how an existing recipient address is updated to the database. 



Web Server 
Application 



addMAddress 
BookServices 



addMAddress 
BookManager 



^1 : CreateAddressBookManagerO 

: >\' 



2: Createi 



v 



1 3: ValidateQ 



4: SaveQ 



addr lAddress 



^3 



Figure 6. Update an Existing Recipient Address. 
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EXHIBIT "C" 



Apr-20-2004 02:37pm Frora-ALSTON AND BIRO 



4048817777 



> 

CL 



T-825 P.00I/002 

ZM> UU* Avemic Nonh« jsi 
Bcllevuc, WA 9S005 
Tel;42J,mi5l2 
fa<; A2S.ZT1M01 



F-614 



LI 
-J 

m 
< 

I 

CO 
LU 

CD 



Moveltl Software, Inc. 

Ort-llns shipping fvt cvioWc' cvttywHgn-* 



November^, 1997 



Donald B. Mask 

President and Chief Executive Officer 
College Enterprises. Inc. 
2J201 Victory Blvd,, Suite 270 
Ceooga Pir^CA 91303 

R£: LETTER OF INTENT 

Deer Don: 



The following provide* * summary of business termj for tbe installation and operation of hiovtht 
Web-based shipping systems at CEJ's Pulie Cenien and Special Tearni cempuses- 



Pirtlei 



Busings Proposition 



Term 

EactasJvKy 
Revenue Sharing 



College Enterprise* Inc. ( H CED 
Attn: Donald B, M«k ( President <fc CEO 
21201 Victory Blvd., Suite 270 
CanogaPjrfc.CA 91303 
Tcl:8JMM-0560 

Movtltl totftwart, Jim (WovtJtr) 

Attn: Stephen M, Tcglovic, President it CEO 

2515 140* AVenue NorthOfcsl 

Be1lovue r WA9oQ05 

Tel; 425J72. 15 12 

CEI and Afove/r/ will enter into a business alliance whereby Moveltl will Install 
Web*baied shipping stations ("Stations") in Pulse Copy A Technology Centers 
("Pulse Center?") and on Special Teems ceropUMs. This process will be tindertalfcn 
in three phases; 

t Phi ee One: develop Stations, launch bfowti! Web Client md Network 
Operations Center (NOC) for Instillation in Pulse Cento* to serve 
<mdcnts/fow-YoJume shippers; 

t Phu i Twoj Integra* CHI' a Sppelil Teems debit cards to Increase convenience 
of the payment process; end 

» - Phise Three: expand to include university depurcmtfual business 

This business alliance will he vc fin initial lerm of five years, sutyect To earlier 
termination by either party for breach by (he other. 

Subject to the terms contained herein, CEI and Afovcfr/ will work exclusively with 
.*ch other en offering shipping eexvices on US college cam&usos Ikied In i 
sehedulo to be attached to the definitive agreement. 

CEI end Afov*/// ngree to share 50/50 In ihe "gross profit*" generated by psckage 
shipments thai ire the result of shippers using the Movcli! Station* K Puts* Centers 
or elsewhere on colleges ind universities reprtimied by CEI, For purposes of tUi 
letter of lment, "gross profit" shall be defined simply as tbe difference between the 



> 
a 



Apr-20-2004 02:37pm 



LI 

5 



I- 

o 
u 
a 



F ronr ALSTON AND BIRO 4048817777 T-825 P. 002/002 F-614 

CE! cuiiomer char&e l»,e. ihc shipper) and me uctuai snipping ^ITu^ £Zi? 



Obligation* or the 
Perries 



iDteUtctuiI Property 



Donald B. Mask 
November 24, IW 
Pagt Two 

thlrd-parry carrier. Eeeh party shall be responsible for its ow 0 operating e**eBjes 
relating lo the Stations end Mowtti shipping ayjicm. Wove/*/ will not ehuga "I 
or the Pulse Centers for ihp development costs ofthe technology or for iho 
operation ofthe Ateva/r/ WOC, 

CE1 will own/lease, operate end maintain the Station* et itt expert*. A/ovWtf wtU 
provide technology, syntmj t«-up md coordination, training nhd customer support 
for the Station! it Its expense. CEI md Mo»*ltl will work togolher diligently lo 
define the requirements, marketing plan and deployment plan for Iho three phases 
defined above* 

Movcitf will own all intellectual property developed oy It relating to the Stations 
and will provide CEI with i nonekchulve license (lunject to the exclusivity 
provision above) to use inch intellectual property In connection with the operation 
or the Slalom in Pulse Center*. 

Schedule MovcM agrees to Initall « Beta version (lb* "Beta") ofthe Station tl a -elected 

Pulse Center Tor the Pbaie One customer group approximately five to six months 
after execution ofthe definitive agreement. Said Beta will be In operation between 
30 and 90 days based on acceptance criteria spelled out In the definitive agreement 

Condition* CEI agrees to deploy the StaUons promptly in each new Pulse Cemer It opens 

during the icon orthe definitive agreemenl- 

Utter of Intent The Parties understand and agree that these summary lenn< are non-blodlng and 

will not be effective until i definitive igreemem is executed by *e Parties and 
ratified by the Panics 1 respective Poaxds of Directors. 

Don, we're troly excited about this business alliance and appreciate In advance your and your 
colleagues' help during the development process end bets testing. Would you kindly acknowledge your 
agreement with thn terms herein by signing In the speea provided below and 1 will Instruct our attorney to 
begin drafting a definitive agreement. We look forwird to a long and rewarding partnership with you and 
CEI. 



Sincerely, 



Stephen M- Teglovlc 
Preildent & CEO 



AclcnoyMiged andaareed onjtfecvnber 

Boirtld B, Mast PreSident * CEO 
College Enierpriaeshno. 

SMT/ms 

cc: Movohf Software, Inc. Board of Directors 
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6. Web Site Overview 

Most web sites found on the Internet are collections of organized web pages which, although 
organized, can be traversed in an unordered fashion. These informational web sites can be 
discovered through multiple links and their pages bookmarked for later retrieval. The average web 
user has grown accustom to waiting for graphics and content to download over their limited internet 
connection, for all web sites are brought to the web user's browser through the same small pipe. The 
Movelt! web site is different from the traditional web site, for it provides more than just an information- 
based collection of web pages. It provides a set of services and is compared more to an application 
that is running on the web user's machine. Applications have a whole different set of performance 
requirements in order to be perceived acceptable to the user. Because of this comparison to an 
application, we have had to mimic the flow that is associated with an application while working with 
the limitations imposed by a web browser's abilities and connections across the internet. 

The web applications, which the Movelt! web site provides, have had to overcome the unique set of 
challenges are imposed when designing a tool perceived as both an application and as a web site. 
Some of the solutions we implemented are: 

• Keeping frequently used information in a web page cache and web browser cookies. 

• Maintaining an application's state with client cached information. 

• Providing secure information transactions with secure socket layers and session keys. 

• Using pop-up browser windows to maintain an application's state while performing subtasks. 

• Validating forms on the client side to stop simple errors from requiring a server round trip. 

Because of the nature of a web site, the design needs to be both flexible and extendible. Some of the 
ideas we have incorporated into our design are: 

• Stateless program flow to allow for interaction with multiple web servers. 

• Code reuse with shared set of commonly used JavaScript functions and HTML. 

• Data driven screen forms 

6.1 Web Site Performance 

Speed is the measure of performance for which the Movelt! web site must optimize. Due to this 
requirement,: the web site applications use a number of techniques to minimize the number of client 
web browser and web server transactions. One of the slowest processes of the web site is the 
transferring of information between web browser client and web server. Every time a web user clicks 
on a hypertext link, a round trip of information to the server must take place for the retrieval of content 
for the next web page. The following areas explain methods of improving the web site performance. 

6.1.1 Client Form Validation 

When a user puts information into a form on a web page, they will need to submit it back to the web 
server to have their data validated and processed. To alleviate some unnecessary round trips, simple 
validation can be performed on the client browser through JavaScript The types of validation that 
can be performed on the client include: 

• Verifying there is content in required information fields 

• Checking for the tt @" symbol in an email address. 

• Preprocessing alpha or numeric only separation. 

• Required number of password characters 

• Changing password content confirmation 

If these simple checks find invalid or missing data, they can immediately be brought to the attention of 
the web user rather than having their form make the round trip only to find that a simple mistake. 

The process for performing the client validation involves JavaScript, which is called in one of several 
methods. The JavaScript can be called when a submit form button is clicked or from a number of 
different events like OnBlur, which triggers when the current field loses focus. An example of 
validation is the confirmation of a user's password. Passwords are entered into inputs of type 
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"password", which have the added security measure of echoing typed characters as asterisks. Below 
is some sample HTML for a password input, a confirmation password input, and a submit button. 

<FORM NAME— "Te3t"> 

Password: <INPUT TYPE-PASSWORD NAME-"Passwordl M SIZE=15> <BR> 
Confirm: <INPOT TYPE=PASSWORD NAME~"Pa33word2" SIZE=15> <BR> 
<INPUT TYPE- BUTTON VALUE™ "SUBMIT" OnClick- ,, Conf irm { ) "> 
</FORM> 

The button input has an OnClick event that is set to call the function Confirm. The corresponding 
JavaScript verifies that the information matches and alerts the user if there is an inconsistency. 
Otherwise;- the form is sent to the web server. 

; . ; : <SCRIPT LANGUAGE="JavaScript"> "-"-V--; 
<! — 

function ConfimU) 
: . .■ r if( Test . Password!. !« Test.Password2 ) 

alert ( "Your password and confirmation do not match." ); 

else . ■ ■ . . ; 

. • . { . . .' .... . 

Test. submit 0 ; . : 

:■, > , • • • .' .: • 

. ) . 
//—> 
</SCRIPT> 

Through JavaScript, a number of similar operations can be used to prevent server round trips on 
simple mistakes. 

6.1.2 Client Information Caching 

Once information has been validated and determined acceptable or it has been sent from the server 
once, it is desirable to not transfer the information every time it is required for display. Some data is 
stored in the client web browser, hidden from view. This "cached" data can be stored and retrieved 
through client JavaScript. For example, once a user has logged on to the Movelt! system, their 
browser is passed a Session Key. The next transaction the web user makes will jnclude their Session 
Key, which was held in their cache page. A new Session Key will be generated on the server and 
sent with the next page the client web browser receives. Another example of caching client 
information is the storing of data which is being accumulated over several pages and submitted at 
once for validation. 

6.1.3 Selective Secure Transfers 

When information needs to be sent between the client web browser and the web server and the 
information needs to be kept secure, the web page is through a secure socket. To make a socket 
secure, all messages sent through it are encrypted and then decrypted upon their arrival. 
Unfortunately, the process used to encrypt and decrypt information involves manipulating the data 
stream with complicated math functions and large numbers. This process, although very secure, is 
very slow. To alleviate the process for the web user, only selective information is transferred with a 
secure socket. 

A large amount of the information which is contained within the web site is considered customer non- 
specific because most customers view it at some point By keeping only customer specific 
information secure, the bulk of the data transfers are not penalized by security. One way this is 
accomplished is that frames that do not contain content that needs to be secure are not passed 
through a secure socket Other broadly viewed objects in HTML web pages are graphics, which are 
referenced and transferred individually. Most graphics do not need to be kept secure and do not need 
to be sent through secure sockets. Because graphics are comprised of many more bytes than the 
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by User 




9.1.2 


Figure 6. 
Recipient Report 
by User 


Recipient company name 


9.1.3 


Figure 6. 
Recipient Report 
by User 


Recipient address 


9.2.1 


Figure 6. 
Recipient Report 
by User 


Package reference No. 1 


9.2.2 


Figure 6. 
Recipient Report 
by User 


Movelt! tracking number 


9.2.3 


Figure 6. 
Recipient Report 
by User 


Service 


9.2.4 


Figure 6. 
Recipient Report 
by User 


Service options 


9.2.5 


Figure 6. 
Recipient Report 
by User 


Carrier 


9.2.6 


Figure 6. 
Recipient Report 
by User 


Package status 


9.2.7 


Figure 6. 
Recipient Report 
by User 


Ship date 


9.2.8 


Figure 6. 
Recipient Report 
by User 


Total package charge 


9.3.1 


Figure 6. 
Recipient Report 
by User 


Number of packages for each group 


9.3.2 


Fiigure 6. 
Recipient Report 
by User 


Total charges for each group 


9.3.3 


Figure 6. 
Recipient Report 
by User 


Total number of packages 


9.3.4 


Figure 6. 
Recipient Report 
by User 


Total package charges 


10 


Figure 6. 
Recipient Report 


Select custom reports 
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by User 



Table 4.Reporting Application Requirements Traceability Matrix 



i 
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8.1.2 Shipping Application 
8.1.2.1 Overview 

The Web Shipping Application provides the means by which the necessary information for preparing a 
package for shipping at a local drop-off site is entered. The package information gathered by the 
application consists of 

• The destination address of the package 

• The drop-off site 

• The package weight and dimensions 

• The carrier, service and service options 

• Miscellaneous notes and reference information 

This informnlion is gathered in two phases - the "Submit" phase nnd the "Ship" phase. 

During the "Submit" phase a data entry form is displayed for entering the destination address, the 
drop-off site, the package weight, dimensions, and miscellaneous package notes and reference 
information. A blue label next to an entry area indicates a required field. Specific instructions 
describing what must be entered for any field - required or optional - is obtained by simply clicking on 
the label, and the instructions appear in an information window. Once all the required information is 
entered, the information is submitted by selecting the "Submit" button. At this point the information is 
validated for completeness and correctness. If any items are invalid, the labels of the invalid fields are 
turned red, and the focus is set to the first invalid, data entry field. Clicking on a corresponding red 
label brings up an information window describing the error and what needs to be done to correct the 
error. After the invalid fields are corrected, the information is re-submitted by selecting the "Submit" 
button. This cycle continues until all the required data is correct and complete. When the "submitted" 
is valid, the "ship" phase commences. 

During the "ship" phase a summary of the entered information is displayed along with a rate matrix 
and a service options selection area. Each cell of the rate matrix displays the rates for shipping the 
package via carrier / service combination. Initially, these cells either contain the base rates for 
shipping the package for each carrier and service or "NA" (Non-Applicable) if the service is not 
available for a carrier or a carrier does not support the service for the destination of the package. The 
service option area contains checkboxes for selecting one or more service options and associated 
data entry fields for the service options. A blue label distinguishes required service option entry fields 
from optional fields. Specific instructions for each service option, data entry field is obtained by 
clicking on the label of the data entry field, and the instructions appear in an information window. As 
one or more service options are selected, the rates in the rate matrix are adjusted to include the 
selected service option charges. If a service does not support a selected service option, the rate 
displayed in the cell changes to "NA\ 

To "ship" a package a service must be selected. The service to be used to ship the package is 
selected by clicking any cell in the rate matrix that does not have "NA". Once a service is selected, 
selecting the "Ship" button will ship the package. At this point the service and service option 
information is validated. Any invalid entries will most likely be due incomplete or incorrect service 
option supporting Information. The labels of the invalid items are turned red and the focus is set to the 
first invalid field. As in the "submit" phase, clicking on the label of an invalid field brings up an 
information window describing the error and what to do to correct the error. After correcting the invalid 
fields the, package is re-shipped by selecting the "Submit" button. This cycle is repeated until all the 
required fields are valid. 

Once the package has been shipped, the Web Shipping Application enters the final, non-data entry 
phase. During this phase a final summary is displayed showing the package information displayed 
earlier during the start of the "Ship" with the addition of the selected carrier, service, service option(s) 
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and associated data, an application generated tracking number, and up to five rates for the package. 
The five rates represent the rates for the package weights that bracket and include the billable weight 
of the package. If the shipped package is a letter only one rate is displayed. 

In each of the three phases of the Web Shipping Application several buttons are displayed along with 
the other phase related information. These buttons are the means by which the Web Shipping 
Application navigates the web pages that comprise the application. During the "Submit" phase three 
buttons are displayed: 

• A "Locator" button for selecting the drop-off site of the package. A separate window is brought up 
for selecting the drop-off site. 

• A "Cancel" button for resetting the package information on the "Submit" web page back to the 
system defaults and user preferences. 

• A "Submit" for submitting package information for validation. 
During the "Ship" phase three button are also displayed: 

• An "Edit" button to edit the current package information. 

• A "Cancel" button for resetting the package information entered on the "Submit" web page back to 
the system defaults and user preferences 

• A "Ship" button to store the package information 

During the last phase two buttons are displayed along with the final summary information 

• A "Ship Another Package" button for shipping another package. 

• A "Done" button for exiting the Web Shipping Application. This button is a duplicate of the "Done" 
navigation button and is provided as a convenience on this last page. 

8.1.2.2 Structure and Identification 



Attribute 


Value 


Prefix 


ship 


Directory Name 


Shipping 



Table 5. Shipping Structure and Identification 



8.1.2.3 User interface Design 
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8.1.2.4 Transact! nSets 

This table below describes the transactions that the Web Shipping Application will have with the Web 
Server. 



Transaction Sets 

j 








Submit package information 


Validates the package information. If successful, a rate matrix is 
returned. Otherwise, the list of invalid package fields and 
corresponding error and correction text is returned. 


Ship a package 


Validates the package information. If successful, a set of rates 
bracketing and including the billable weight rate is returned. 
Otherwise, the list of invalid package fields and corresponding 
error and correction text is returned. 


Edit a package 


The current package information is retrieved from the server and 
the initial Shipping data entry page is populated with the package 
data. 



Table 6. Shipping transaction Sets 



8.1.2.5 External Dependencies 

The physical dependencies that the Web Shipping Application has are: 



Type 


Name 


Description 


Utility Package Classes 






COM Object 


shipJShipping 


Shipping COM object 


COM Object 


ship J Package 


Package COM object 


COM Object 


shipJRatelnfb 


Rating Information COM object 


COM Object 


shipJServices 


Service and service option COM 
object 


COM Object 


I Dictionary 


Microsoft dictionary 


DLL 






Static Library 







Table 7. Shipping External Dependencies 
8.1.2.6 Requirements Traceability Matrix 

This table lists all the individual line item requirements met by the Shipping application 



Requirement ID 


Figure 


Comments 
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9.3.8 Database Servic s 

9.3.8.1 Overview 

The database services will provide Wolverine sever components with database connection 
handling methods. ^ 

Because of the database-distributed architecture, server components will connect to different 
databases on different servers. The database services will make sure each component connects 
to the right server and the right database, as well as implementing a failure recovery scheme if a 
connection fails. 

9.3.8.2 Structure and Identification 

Table 1.1.1-1 defines.the naming prefix used to define objects within the component and it defines 



the name of the component. 


Attribute 


Value 


Prefix 


dbs 


Name 


database 


Type 


DLL 



Table 20. Database Services Structure and Identification. 



9.3.8.3 Exported Interfaces 
9.3.8.3.1 Classes 

This section defines the classes that are exported from the Reporting service. Each class is 
defined in a table that describes its methods and properties. 

dbsJTDatabaseServices 

The methods of the dbsJTDatabaseServices object take a securJUser interface pointer and 
provide access to the dbsJTDatabaseAdmin objects. 

The table below shows methods and properties of dbsJTDatabaseServices. 
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dbsJTDatabaseServices 


Default constructor that initializes class data members. Copy 
constructor is private and not implemented. 


~ dbs_TDatabaseServices 








CreateDatabaseConnection() 


Returns a database connection interface pointer. 






<None are required> 








<None are required> 





Table 21. Class dbsJTDatabaseServices Descriptio 



dbs_TConnection 

The dbs_TConnection prepares the SQL statements. It also exposes the dbs_TStatement object, 
which allows execution of statements. The table below shows methods and properties of 



dbsJTConnection. 






Mmmmsmmmmgmgmm 






dbsJTConnection 


Constructor takes connection handle and assigns it to member 
data that holds this value. Default and Copy constructor is private 
and not implemented. 


~ dbsJTConnection 










CreateDatabaseStatement 


Returns a database statement interface pointer. 


GetConnection 


Allocate a connection handle and returns a connection interface 
pointer. 








<None are required> 








<None are required> 





Table 22. dbsJTConnection Description. 
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dbs_TStatement 

The dbs_TStatement executes the SQL statements. The table below shows methods and 



properties of dbsJTStatement. 










dbsJTStatement 


Default Copy constructor initialize all member pointers to Nulls. 


- dbsJTStatement 


Free all pointers allocated 






Init 

II Hi 


Rpctrirff»H mpthnri that initiali7pc an allnratpri ^tatpmpnt handlp 


FillMap 


Restricted method for saving results in a map 


Cleanup 


Restricted method for releasing resources 


BindColumns 


Restricted method for binding columns used in ODBC SQLFetch 


Execute() 


Executes the statement. It will bind parameters if there are any 

onrl fatr»h rtnlw fKa dDCT rar>r\rri cot if it'c o CO lor"* t ctsitompflt 

ana ieicn oniy me rir\o i record sei it us a scicui t> leucine in. 


Prepare 


Takes the SQL statement and allocate a statement handle. It 
men prepares tne siaiemeni. Ana iLreiurns a Siaiemeni iiuenave 
pointer. 

It is aiso passed flag that indicates if the statement is a select 
statement or not. 


GetNext 


Used only after executing a select statement Execute will return 
the first row of the result set. Next will get the next record. 


GetFirst 


Move to first record 


GetLast 


Helper function for navigation. Used only after executing a select 
statement. It returns the last row. 


MoveAbsolute 


Moves to h record if exists 


MoveRelative 


Moves n records relative to current position 


GetPrevious 


Returns previous record from current position 


IsBOF 


Helper function for navigation. Used to determine the beginning 
of a result set 


IsEOF 


Helper function for navigation. Used to determine the end of a 
result set, will call before NextQ is called to determine if there is a 
next record 






<None are required> 









Document: P-DD-97-0910 
Modified: 01/07/9S 6:47 PM 



CONFIDENTIAL 



Page 291 



Movelt! Software, Inc. 



CONFIDENTIAL 



Project Wolverine Design Document 



<None are required> 



Table 23. dbsJTStatement Description. 
9.3.8.3.2 Free Functions 



Free functions are defined in the table below. Free functions are functions not associated with a 
particular class. 







Description 


<Noneare required> 





Table 24. Free Function Descriptions 



9.3.8.3.3 COM Interfaces 

This section defines the COM interfaces that are exported from the database services. Each 
interface is defined in a table that describes its rtiethods and properties. 



COM Class dbs_DatabaseServices 

The COM Class DatabaseServices provides connection and prepare statements for other server 
components. It implements the following interfaces that are defined in the following table 







ProgID 


MSI.dbs_DatabaseServices 


Supported Interfaces 


d bs J DatabaseServices 




IDispatch 




lObjectControl 




ISupportErrorlnfo 




1 Unknown 



Table 25. COM Class DatabaseServices 



COM Class dbs_Connection 

The COM Class dbs_Connection prepare statements for other server components. It implements 
the following interfaces that are defined in the following table 









ProgID 


MSLdbs_Connectipn 
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Supported Interfaces 


dbsJConnection 




IDispatch 




lObjectControl . 




ISupportErrorlnfo 




1 Unknown 



Table 26. COM Class dbs DatabaseConnection 



COM Class dbs Statement 



The COM Class dbs_Statement executes SQL statements for other server componients. It 
implements the following interfaces that are defined in the following table 









— 




ProgID 


MSI.dbs_Statement 


Supported Interfaces 




dbsJStatement 
IDispatch 

lObjectControl 

ISupportErrorlnfo 

lUnknown 







Table 27. COM Class dbsJStatement 



Interface dbsJDatabaseServices 



A high level interface that allows access to the rptJDatabaseConnection 
The table below shows methods and properties of rptJDatabaseServices. 















CreateDatabaseConnection() 


Returns a database connection interface pointer. 








<None are required> 








if % ¥$$pr£?$' ^ % =0 r ^ot^ 


<None are required> 





Table 28 dbsJDatabaseServices Interface Description. 
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dbsJConnection 



The dbsJConnection prepares the SQL statements. The table below shows methods and 
properties of dbsJConnection. 











CreateDatabaseStatement 


Returns a database statement interface pointer. 


GetConnection 


Allocate a connection handle and returns a connection interface 
pointer. 






<None are required> 








<None are required> 





Table 29. dbsJConnection Description. 



Interface dbs JStatement 



The dbs JStatement object executes SQL statements and verifies data validation before saving 
them in the database. The table below shows methods and properties of dbs JStatement. 





mmmmmmsmBamam 






Jnit 


Restricted method that initializes an allocated statement handle. 


Execute() 


Executes the statement. It will bind parameters if there arei any 
and fetch only the FIRST record set if it's a select statement 


Prepare 


Takes the SQL statement and allocate a statement handle. It 
then prepares the statement. And it returns a statement interface 
pointer. 


GetNext 


Used only after executing a select statement Execute will return 
the first row of the result set. Next will get the next record. 


GetFirst 


Move to first record 



Document: P-DD-97-0910 CONFIDENTIAL Page 294 

Modified: 01/07/98 6:47 PM 



Movelt! Software, Inc. 



CONFIDENTIAL 



Project Wolverine Design Document 



RptLast 


It returns the last row 


M ove A bso 1 u te 


Moves to n record if exists 


Move Relative 


Moves n records relative to current position 


GetPrevious 


Returns previous record from current position 


IsBOF 


Used to determine the beginning of a result set 


ISEOF 


Used to determine the end of a result set. 






<None are required> 






lifinMMBHHHM 


<None are required> 





Table 30. dbsJStatement interface Description. 



9.3.8.3.4 Interaction Diagrams 

To better understand the interactions with database Services and other components of project ; 
Wolverine, interaction diagrams are presented. Each diagram depicts a scenario showing one or 
more components interacting. The diagram does not depict what is going on inside of the 
database services package. It is treated here as a black box. Figure 1.1.1-1 shows how the 
interaction between a Report Web Application and the dbsJDatabaseServices, 
rptJReportServices, rptJReportManager, rptJReportCollection and rptJReport interfaces. The 
diagram depicts a simple error free scenario. In step 1, the web app calls 
CreateObject("ReportServices"). The ReportServices object will call method 
CreateReportManagerQ. Inside.the function CreateReportManagerQ, the following will be called: 



1. Create Database Services passing it a secure user 

2. dbsJDatabaseServices::CreateDatabaseConnection() 

3. dbsJDatabaseCopnnection::GetConnection(). This function establishes the connection and 
prepares statements that can be prepared in advance. 

4. Once a connection is established, then the function CreateReportManager() will Create 
Report Manager object, passing it the connection and statements handles. 



The report manager then uses the handles to do its work. 
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rplJReport 


rpUReport 


rpt (Report 


rpt IReport 11 dbsJDatabase 




dbs_ 


dbs_ 


Services 


Manager 


Collection 


Services 




IConnectlon 


IStatement . 



1: CreateReportManagerO 

' *£]' 



2: Create Database ServicesQ 



"*0 



3: CreateOatabaseConnectlonO 



4: OetConnectfonQ 



5: CreateDatabaseStatementQ 



6: Prepare() 



7: Find() 



8: ttem() 



D 



-9>r 



|9: GetPropertlesO 



10: Execute( a select statement) 



Figure 6. Report Web application and DatabaseServices Scenario Interaction Diagram 
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9.3.8.3.5 Messages 

The table below defines messages that either Database Services publishes or subscribes to. 



BnHHMHHHHIMI 








STATUS.INFO.DATABASEJNITIALIZATION 


Message sent at the start of initialization. 


^KSWlSi^illli 


|ii 




None are required. 






IT;/ 




STATUS.ERROR.DATABASE.DB_CONNECTION_FAILURE 

STATUS.ERROR. DATABASE. DB_PREPARE_FAI LURE 

STATUS. ERROR. DATABASE.DBJNSERT_FAILURE 
STATUS.ERROR. DATABAS E.DB_U PD ATE_FAI LU RE 
STATUS.ERROR. DATABASE.DB_DELETE_FAILURE 


Couldn't connect to the database during the 
initialization process 

Couldn't prepare ODBC statements during 
initialization process 

Couldn't add a new custom report 

Couldn't update a custom report 

Couldn't delete a custom report 






None are required. 





Table 31. Publish and Subscribe Messages Supported by Database Service 



9.3.8.4 Implementation Details 

9.3.8.4.1 Classes 

This section is the same as section "Exported Interfaces/ Classes". 

9.3.8.4.2 Class Diagrams 
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dbs TDatabaseServices 



*CreateDatabaseConnection( ) 



dbs TConnection 



♦CreateDatabaseStatement() 
4GetConnectipn( ) 



dbs TStatement 



*Execute( ) 
%GetLast( ) 
%GetFirst( ) 
%GetPrevious( ) 
♦GetNext( ) 
%Jnit( ) 
♦IsEOF( ) 
♦lsBOF() 
♦Prepare( ) 
*C!eanUp( ) 
♦BindColumns( ) 
+FillMap( ) 



9.3.8.5 External Dependencies 

The following table lists dependencies that this package has on components and tables. 





mmmsmmsi 




Utility Package Classes 






COM Object 






DLL 






Static Library 


ATL 


Active X Template Library 



Table 32. Database Services External Dependencies 
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7. Rate Shop Application 
7.1.1-1 Overview 

The Rate Shop Application manages the on-screen-rate shopping. The user will be able to enter the 
following shipping information: 

1 - Origin Zip Code or Drop off Location 

2- Destination Zip Code 

3- Expected Drop off Date 

4- Weight 

5- Packaging type 

6- Additional Handling 

Once the above information is submitted, the Movelt! Server components will validate the submitted 
shipping information; if the validation is successful, the Rating page will be displayed otherwise a 
descriptive error will be displayed. 



7.1.1.2 Structure and Identification 









Prefix 


rate 


Directory Name 


Rateshpp 



Table 1. Rate Shop Structure and Identification 



7.1.1.3 User Interface Design 

The Rate Shop application entry page is the Rate Shop page. 

The user enters here the necessary shipping information to get a rate for the package. 

The user will be able: 

1- To enter either an origin zip code or to select a location from a list of available drop off 
locations. 

2- To enter destination zip code 

3- To select expected drop off date from a list of the next seven working days 

4- To select packaging type from a list of packaging types 

If "Your Packing" selection is selected, then the user must enter: 
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• Height 

• Width 

• Length 

5- To select Additional Handling 

Figure 1 shows the Rate Shop page. 
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Figure 1 . Rate Shop page 



Once the information in the Rate Shop page are submitted and validated by Movelt! Server 
components, the Rating page will be displayed. 

The Rating page displays the following: 

1. The expected ship date 

2. Service options controls 

• Declared value 

• Outbound alert 

• Priority delivery notification 

• Verbal confirmation of delivery 

• Saturday delivery 

3. Rate grid. It displays valid rates and services for submitted data and for each carrier 

4. A condensed account agreement 

5. Package weight 
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Figures 2. Shows a screen shot of the Rating page 



13 HDvell! Soltwaie Home - Microsoft Internet Exploicr [&tE 5 [S3 




Figure 2. Rating page 
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7.1.1.4 Data Flow Diagrams 

The Data Flow diagram shows how the user accesses the Web Rate Shop Application, or the Rate 
Shop State "ratejvlairf, from the welcome screen by selecting the Rate Shop selection. 
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^ rateJWain 



Main: Menu: 

Entering necessary [selects] 

shipping data to rate a -Cancel 

package. -Rate 



genjvlain 
or 

cust Main 




Cancel 




Selection 



Rate 

I 



Server validates entered data and 
rate the package according to 
provided shipping data. Server 

returns a Rating page that will be 
generated by ASP code. 



Menu: 
[Selects] 
-Edit 
-Cancel 



Main: 

Displays the generated HTML 
.of the Rating details. 



-Cancel- 



Selection 



-Edit- 



Figure 3. Rate Shop data flow diagram 



7.1.1.5 Transaction Sets 
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This table describes the transactions that the Web Reporting Application will have with the Web 
Server. 



Transaction Sets 



Rate Submit user's necessary shipping data to rate a package and 

return a HTML rating page 



Table 2. Reporting Transaction Sets 



7.1.1.6 External Dependencies 

The physical dependencies that the Web Reporting Application has are: 



Type 


Name 


Description 


Utility Package Classes 


NA 




COM Object 


rate J Rating 
• 


Uses the carrier, service, drop-off site 
and destination information, weight, and 
dimensions to calculate a matrix of rate 
information per carrier and per service. 




bizJBusinessRules 


The main function of this service will be 
to provide validation and calculation of 
small parcel packages. 


Database Tables 




Rate tables 


Static Library 


NA 





Table 3. Rate shop External Dependencies 
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8.1.3 Tracking 
8.1.3.1 Overview 

The tracking application allows the user to gather information about a package that has been 
previously shipped with the Movelt! shipping system. Pertinent information such as delivery status, 
location, and recipient will be returned if available. 

The Tracking Web Application is designed to allow the user to: 

• Track packages shipped through Movelt! with a Movelt! supplied tracking number. 

• Track packages that may or may not have been shipped through Movelt! with a carrier supplied 
tracking number. 

• Track packages from a historical list of packages shipped through Movelt!. 



The Design is intended to be flexible and easily maintained based on the dynamic nature of a Web 
site. The following specific things were kept in mind when designing the Tracking application: 

• Flexible carrier support. 

• Support for variable amounts and types of information provided by carriers. 

• Pass control to history when tracking from history is desired. 



8.1.3.2 Structure and Identification 

The table below defines the naming prefix used to define objects within the application and it defines 
the directory name where all the components of the application will reside when under configuration 
control. 



Prefix 



track 



Directory Name 



Tracking 



Table 8.1.3-1 Tracking Structure and Identification. 
8.1.3.3 User Interface Design 

The following two screenshots illustrate a typical tracking session. 
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8.1.3.3.1 Tracking Number Entry User Interface Design 

illustrates the initial entry to the tracking application. Here the user is prompted to enter a tracking 
number and, if it is not a Movelt! tracking number, what carrier the tracking number belongs to. 
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Figure 13. Main Tracking screen 



8.1.3.3.2 Tracking Result User Interface Design 

The following diagram represents a successful track request using a Movelt! tracking number. Note 
that the user is allowed to immediately track another package from the detail screen. 
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8.1.3.4 Data Flow Diagrams 

The following figure details what happens when a user enters the tracking application and submits a 
tracking request. Note that when an error is made, the flow is similar to a successful tracking request 
except that the detail screen will contain error information insteadof tracking detail. 



c 



Enter Tracking Area 

(T) 



Menu: 

[selects] 

-History 



Return to General Area 
(M) 




> 



Main: 

Allow the user to track 
a single package by 
entering a specific 
tracking number. 
Indicate that a carrier 
must be supplied if not 
using a Movelt! 
tracking number. 



Selection 




History - 



Control is passed 
to Shipping 
History. 



Submit 



Client 
Succeed 




In detail screen, 
indicate that an 
error has been 
made. 
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0 



Menu: Main: 
[selects] Display relevant 

-History tracking information 

below the original 
tracking number entry 
field. The user is 
allowed to enter 
another tracking 
number for tracking. 



6 



8.1.3.5 Transaction Sets 

The table below (Table 6.5.2-1) describes the transactions that the Web Browser will have with the 
Web Server. 











Submit Track Request 


Current tracking information for the entered tracking number. 


Track from History 


Control is passed to the Shipping History view 



Table 8.1.3-2. Tracking Transaction Sets 



8.1.3.6 External Dependencies 

The table below lists dependencies that this application has on other components and database 
tables. 











Database Tables 


Shipment 
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COM Objects 


1 Dictionary 


Microsoft dictionary 


COM Objects 


trackJTrackingServices 


Tracking services 


COM Objects 


trackJTrack 


Tracking interface 


COM Objects 


trackJTrackinglnfo 


Tracking details interface 



Table 8.1 .3-3. Tracking External Dependencies 
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method is called. 


IsDirtyO 


Returns a boolean value indicating whether any property 
has been modified since the object was created. 


lsVa!id() 


Returns a boolean value indicating whether a successful 
validation had been performed since the last property 
change. Does not call the Validate() method. 


IsReadOnlyO 


Returns a boolean value indicating whether this is a read- 
only interface. If it is, the following methods should return 
the BIZ_READONLY_ACCESS_ALLOWED hresult: 

PutProperty() t PutProperties() ( IsPropDirtyO, IsDirtyO, 
lsValid(), and Validate(). 


lsFromStorage() 


Returns a boolean value indicating whether the object was 
originally retrieved from data storage. This is used when 
saving an object back into storage to determine if an Insert 
or Update needs to be performed. 






OID 


The OID (Object Identifier) of the current object (read- 
only) 


ObjectTag 


A human readable name for the object For example 
"REPORT. Names shall be in all uppercase, (read-only) 


Readonly 


Value is either 0 or 1. 1 Indicating the object is read-only. 
If an object is stored in the database as read-only, it will be 

iclllcVcU iniUdliy 111 a IcaU-UIHy olctlc. \l CdunJl liyy 


<List of all other properties and their 
descriptions that can be retrieved from 
the property collection that are 
specific to the particular business 
object These are NOT properties in 
the COM sense.> 





Table 12. Interface bizJBusinessObject 



COM Class Data Dictionary 









ProgID 


MSl.biz_DataDictionary 


Supported Interfaces 


bizJDataDictionary 

IDispatch 

lObjectControl 

ISupportErrorlnfo 

lUnknown 




Interface bizJDataDictionary 
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The data dictionary interface allows for the retrieval of data dictionary items. It also adds a convenient 
function to validate a value against a particular data dictionary entry. 







lnit() . .. ; 


Loads a data dictionary as specified by the passed in name 
from persistent storage. Not required to be used if created 
orginally with bizJDataDictionary interface. 


' :liii^llK|Sil|iiiSlS 




Count() 


Based on a passed in filter string, retrieves the number of a 
DataDictltem objects matching the filter. The count is set to 
zero(O) if nothing matches. 


Create() 


Creates an empty thing. The properties are filled with all 
the property names and any default values are assigned. 
An OID is generated and the Name property is assigned at 
this time. 


CreateFilterUsingExample() 


Uses the properties of the passed in bizJDataDictltem to 
build a filter string that is returned. Use the filter string on 
future calls to methods that require a filter. 


Delete() 


Deletes a DataDictltem using the passed in OID. 


Find() 


Based on a filter string, retrieves the first occurrence of a 
DataDictltem object matching the filter. The returned 
DataDictltem is NULL if no item matches. 


ltems() 


Returns a utilJMap collection; The number and ordering of 
DataDictltems in the collection is determined by the passed 
in filter and the current user. The key field holds OiDs of 
data dictionary items. 


Load() 


Based on an OID retrieves a single DataDictltem object. 


Save() 


Takes a bizJDataDict as an argument and stores it in data 
storage. The Validate() method of uatauictitem is caiiea 
prior to any attempt to store the object. If the object is 
currently in data storage, it is updated otherwise it is 
inserted. 


ValidateValue() 


Takes a VARIANT that represent a possible value for a 
data item of the current type and the name of a data 
dictionary item and validates it. Returns both a boolean 
value and a status code. The status code is used to 
indicate whether the value was modified as a result of the 
validation, for example, converting a string to alt uppercase 
letters. 






None are required. 
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Interface bizJDataDictltem 

This is an implementation of the bizJBusinessObject interface. This interface is only used in 
conjunction with the Data Dictionary Administrator to create and save data dictionary items. The 
properties are defined below in the bizJDataDictltemReader. 

Interface bizJDataDictltemReader 

The table below defines the data dictionary item interface. This interface is only used in conjunction 
with the Data Dictionary Mangager to retrieve data dictionary items for read-only usage. 







iiiroi^ 




None are required. 








GetProperties() 


Creates and returns an 1 Dictionary interface of properties. 
Wildcards are supported that allow filtering of the returned 
properties. 


GetProperty() 


Returns the value of a single property as a VARIANT. The 
property is indexed by a key. 


GetPropValidValues() 


Takes a property name and returns an IStringList interface 
of allowed values. Used for example to populate a list box. 


ValidateValueQ 


Takes a VARIANT that represent a possible value for a 
data item of the current type and validates it. Returns both 
a boolean value and a status code. The status code can be 
used to indicate whether the value was modified as a result 
of the validation, for example, converting a string to all 
uppercase letters. 






Default 


VARIANT representing a default value if one applies. 


ID 


A unique integer identifier that represents this data 
dictionary item. 


Max 


Maximum allowed value. For strings this equal to the 
maximum allowed length (number of characters). 


Min 


Minimum allowed value. For strings this equal to the 
minimum allowed length. 


Name 


The name of this data dictionary item. For example: 
ADDRESS.POSTAL_CODE. 


NullValue 


Contains a value that is appropriate with this data diet, item 
to represent NULL 


ObjectName 


Object name. Always set to "DATADICTITEM" (read-only) 


OID 


The OID (Object Identifier) of the current object, (read- 
only) 


Precision 


Number of allowed digits to the left of the decimal point. 
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Seals 


Number of digits to the right of the decimal point. 


SQLType 


Integer represent the appropriate ODBC SQL type to store 
data that maps to this data dictionary item ; 


Traits 


Bitmask of traits. The traits are: 

Uppercase, Lowercase, Mixed, Nullable, Defauitvai, 
HasSet, StripWhite, StripReturn, Read-only, 


ValidVaiues 


Contains a SafeArray of Variants that contain a set of 
allowed values for this item. 


VariantType 


Onfe of the VT_ types for data that maps to this data 
dictionary item. 



9.3.5.3.4 Class Diagrams 
None are required. 
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9.3.5.3.5 Interaction Diagrams 

The interaction diagram below (Figure 3). shows how a typical Server Component would use the data 
dictionary object to validate data prior to saving it in the database. The diagram should just one call to 
Vaiidate(). In most cases this method will be called for each data item that has been modified. 



Web 
Application 



1: CreateObject 



2: CreateQ 



3: SaveQ 



Server 




biz (Data 




biz IDataDict 




Database 


Component 




Dictionary 




Item 







->J: 



ValidateQ 



J 



5: InitQ 



I 

6: "Connect and prepare SQL" 

1 ^ 



D 



7: ValidateValue() \ 

->n8: FindQ 



I 



9: "SELECT" data dictionary item. 



10: ValidateValue()| 

' — 

i 



11: "INSERT' validated 



data. 



I 



Figure 3. Interaction Diagram showing how the Data Dictionary interfaces can be used. 



9.3.5.3.6 Messages 

The table below defines messages that either <Gadget> Services publishes or subscribes to. For 
more information on messages, see the Event Services design section in this document. 



Document: P-DD-97-0910 
Modified: 01/07/98 6:47 PM 



CONFIDENTIAL 



Page 255 



Moveltl Software, Inc. 



CONFIDENTIAL 



Project Wolverine Design Document 















BUSINESS.DATADICTIONARYJ-OADED_SUCCESSFULLY 


Message sent whenever a data 
dictionary is loaded. The name of 
the dictionary is included as a 
message parameter. 






None are required. 








BUSINESS.DATADICTIONARY_NOT_FOUND 


Error message if a data dictionary 
with the requested name cannot 
be located. 






None are required. 





Table 13. Publish and Subscribe Messages Supported by Business Rule Services. 



9.3.5.4 Implementation Details 

None are required. 

9.3.5.4.1 Classes 
None are required. 

9.3.5.4.2 Class Diagrams 

9.3.5.4.3 Free Functions 
None are required. 

9.3.5.4.4 interaction Diagrams 
None are required. 
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9.3.5.5 External Dependencies 

There are many database dependencies that will need to be added; 







HDnHH 


Database Table 


DATADICTIONARY 


Table that stores all the 
datadictionary information. 


Utility Package Classes 


util_Error 




COM Object 


CVariantDictionary 


Microsoft Variant map class. 


DLL 




None are required. 


Static Library 


ATL 


ActiveX Template Library 



Table 14. Business Rules Service External Dependencies 
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9.3.5.6 Requirements Traceability Matrix 

The table below traces functional requirements to this design section. 



■■■■■■■■ 

















Table 15. Business Rule Services Requirements Traceability Matrix 
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9.3.6 Carrier Connectivity Services 

9.3.6.1 Overview 

The purpose of the Connectivity service is to allow a standard interface for communicating with 
various carriers electronically. Each carrier will have its unique method for sending electronic 
data for example UPS currently uses a custom protocol called UPSLink/Z for which ups provides 
a communications DLL. Since each carrier will have its own form of communications the 
connectivity service will provide a single interface that can be used to send electronic data to any 
of the carriers. 

9.3.6.2 Structure and Identification 

The table below defines the naming prefix used to define objects within the component and it 
defines the name of the component 







Prefix 


conn 


Name 


Carrier Connectivity 


Type 


DLL 



Table 9.3.6-1 . Carrier Connectivity Structure and Identification. 
9.3.6.3 Exported Interfaces 

Exported interfaces are all classes, free functions, & COM interfaces that other packages may 
need to use. In other words, these are the services that this package is providing. Function 
arguments are described but not shown. This is done to make the document more readable and 
maintainable as the design evolves. 

9.3.6.3.1 Classes 
None are required. 

9.3.6.3.2 Free Functions 
None are required. 
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9.3.6.3.3 COM Interfaces 

This section defines the COM interfaces that are exported from the Carrier Connectivity. Each 
interface is defined in a table that describes its methods and properties. 

Interface conn JCarrierConnect 

A description of the interfaces roles and responsibilities goes here. 




B^&^&^ : ^M^^h^}\ ii", -Ji JwLil&jl ifejlijlilll^ilH $itik$br!&&rM ari;4i&^foj& to&^Mk&ti 



ProgID 



MSI. conn ICarrierConnect 



None are required. 



".Sni5;i.~-f.A--b-l.i. 



GetDirectTrackinglnterface() 



This method will provide an interface pointer that can used for 
package tracking through a direct connection to the shipper. 



Parameters: 



An enumerated constant that represents that carrier that the 
package should be tracked through. 



A pointer to an connJDirectTrack interface pointer. 



GetWebTrackinglnterfaceQ 



This method will provide an Interface that can be used for package 
tracking through the Web sight of the carrier. 



Parameters: 



A pointer to a conn JWebTrack interface pointer. 



GetRegistrationParametersQ 



This method will be used to get a collect of all parameters that are 
required to register a shipper with a give carrier. The caller will 
then be able to enumerate over the collection and fill in all of the 
data that is required by the carrier to register a new shipper. 



Parameters: 



An enumerated constant that represents the carrier that the shipper 
will be registered with. 
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A pointer to an IMap interface that will be filled in with the 
parameters that are required to register the shipper. 


RegisterShipper() 


This method will be used to register a shipper with a given carrier. 
This function is synchronous and will return until the shipper has 
either been registered successfully or an error has occurred that 
blocks the shipper from being registered. 

Registration can be a lengthy process so the caller should take into 
account that the thread will be blocked, (registration can take up to 
5 minutes with UPS) 

Parameters: 

An enumerated constant that represents the carrier that the shipper 
is to be registered with. 

A pointer to an IMap interface that contains that parameters that 
are required to register the shipper. 


GetManifestParameters() 


This method will be used to get a collection of all parameters that 
are required to send a manifest to a particular carrier. The caller 
will then fill the collection with the required parameters for the 
particular carrier and use the SendfManifest method to send the 
electronic manifest. 

Parameters: 

An enumerated constant that represents that shipper that the 
electronic manifest will be sent to. 

A pointer to an IMap interface that will be filled in with the 
parameters that are required to send the electronic manifest. 


SendManifestQ 


This method will be used to upload an electronic manifest to a 
specific carrier. This method will be called asynchronously and will 
return right away. The manifest will be queued for sending and a 
connection to the carrier will be initiated. 

Parameters: 

An enumerated constant that represents the carrier that the 
electronic manifest should be sent to. 

An IMap interface that contains the parameters that are necessary 
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to send the electronic manifest. 

A string of the UNC filename for the electronic manifest. 






None are required. 





Table 9.3.6-2. connJCarrierConnect Interface Description. 
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Interface connJDirectTrack 

This the interface that will be used for tracking directly with the carrier. 



■■■■ 




111 






mm 


ProglD 


MSI.connJDirectTrack 


flHHHHM 




mmmm^mmm 


Connect() 


This method will establish a connection to the carrier. 


Disconnect() 


This method will disconnect from the carrier. 






m 


Iplplil^iiiiliisSlpIl 


GetPackageTrackingParamete 
rs() 


This method will be used to get a collection of parameters that are 
required to track a package. 

Parameters: 

An IMap interface that will be filled in with the parameters that are 
required to track the package. 


TrackPackage() 


The method will do the direct tracking of the package with the 
carrier. 

Parameters;: 

An IMap interface that contains that parameters that are required to 
track the package. 

A pointer to an (Stream interface that will be filled in with the raw 
tracking data returned from the carrier. 






iliiiiiiliiifsiiili 


None are required. 





Table 9.3.6-3. connJDirectTrack Interface Description. 
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Interface conn JWebTrack 

This the interface that will be used for tracking using a carrier's web site. 









liillia^ 


ProgID 


MSI. conn JWebTrack 


IlpmililaM 




Connect() 


This method is used to initial the TCP/IP connection to the carrier. 


Disconnect() 


This method will free up any resource that are being used for the 
TCP/IP connect. 






GetPackageTrackingParamete 
rs() 


This method will be used to get a collection of parameters that are 
required to track a package. 

Parameters: 

An enumerated constant that represents that carrier that the 
package will be tracked through. 


TrackPackage() 


This is the method that will hit a carrier's WEB site to track a 
package. 

* 

Parameters: 

An enumerated constant that represents the carrier that the 
package will be tracked through. 

An IMap interface that contains all of the parameters that are 
required to track a package. 

An IStream interface that will be filled with the raw HTML returned 
from the carrier WEB site when the package is tracked. 






None are required. 









Table 9.3.6-4. connJWebTrack Interface Description. 
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9.3.6.3.4 Interaction Diagrams 

To better understand the interactions with Carrier Connectivity and other packageand 
components of project Wolverine, interaction diagrams are presented. Each diagram depict a 
scenario showing one or more components interacting. The diagram do not depict what is going 
on inside of the Carrier Connectivity. . It is treated here as a black box. . 



Typical interaction between a tracking client and carrier connectivity. 

The following interaction diagram shows how a tracking client would use Carrier Connectivity to 
track a package using the carrier WEB site. 



Example Web > 
Tracking 
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Connectivity : conn 
" TCamerConnect 



jl 1 : connJCarrferConnect ( ) 
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[3: GetWebTracklngObject ( ) 
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Figure 9.3.6-1. Tracking client and carrier connectivity interaction. 
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9.3.6.3.5 Messages 

The table below defines messages that either <Gadget> Services publishes or subscribes to. For 
more information on messages, see the Event Services design section in this document. 





i 








None are required. 






35 




None are required. 






II 




None are required. 






^pillljgigiiiiilM 


None are required. 





Table 9.3.6-5. Publish and Subscribe Messages Supported by Carrier Connectivity 
Services. 



9.3.6.4 Implementation Details 

9.3.6.4.1 Classes 

Class connJTCarrierConnect 

This is the class that implements that conn JCarrierConnect Interface. 




~conn_TCarrierConnect() When the constructor is called any acUve connections to carriers 

will be disconnected. 



conn_TCarrierConnect() There will only be a default constructor. 

GetDirectTrackingObject() This method will provide an object pointer that can used for 

package tracking through a direct connection to the shipper. 



Parameters: 



An enumerated constant that represents that carrier that the 
package should be tracked through. 



A pointer to an conn_TDirectTrack pointer. 
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Thic mothnH u/ill nrnwirlo on Intorfcmo that ran hf* IIQPrl for nprkanp 

tracking through the Web sight of the carrier. 
Parameters: 

A pointer to a connJTWebTrack pointer. 


GetRegistrationParameters() 


This method will be used to get a collect of all parameters that are 
required to register a shipper with a give carrier. The caller will 
then be able to enumerate over the collection and fill in all of the 
data that is required by the carrier to register a new shipper. 

Parameters: 

An enumerated constant that represents the carrier that the shipper 
will be registered with. 

A pointer to an IMap interface that will be filled in with the 
parameters that are required to register the shipper. 


RegisterShipper() 


This method will be used to register a shipper with a given carrier. 
This function is synchronous and will return until the shipper has 
either been registered successfully or an error has occurred that , 
blocks the shipper from being registered. 

Registration can be a lengthy process so the caller should take into 
account that the thread will be blocked, (registration can take up to 
5 minutes with UPS) 

Parameters: 

An enumerated constant that represents the carrier that the shipper 
is to be registered with. 

A pointer to an IMap interface that contains that are parameters 
that are required to register the shipper. 


GetManifestParameters() 


This method will be used to get a collection of all parameters that 
are required to send a manifest to a particular carrier. The caller 
will then fill the collection with the required parameters for the 
particular carrier and use the SendfManifest method to send the 
electronic manifest. 

Parameters: 
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An enumerated constant that represents that shipper that the 
electronic manifest will be sent to. 

A pointer to an IMap interface that will be filled in with the 
parameters that are required to send the electronic manifest. 


SendManifest() 


This method will be used to upload an electronic manifest to a 
specific carrier. This method will be called asynchronously and will 
return right away. The manifest will be queued for sending and a 
connection to the carrier will be initiated. 

Parameters: 

An enumerated constant that represents the carrier that the 
electronic manifest should be sent to. 

An IMan interface that contains the oarameters that are necessarv 
to send the electronic manifest. 

A string of the UNC filename for the electronic manifest. 




toiil! 


siSfSSiiiiKiiiSiiisiiissiiii 


None are required. 










None are required. 





Table 9.3.6-6. conn_TCarrierConnect object Description. 
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Interface connJTDirectTrackXXXX 

This is an example class for direct tracking. There will be a separate class for each carrier since 
direct tracking with a carrier will be very different for each carrier. For example UPS used a 
proprietary protocol UPSLink/z that is implemented by UPSLINK.DLL provided by ups. For this 
reason there will be a separate class that will implement the connJDirectTrack interface for each 
carrier. 











conn_TDirectTrackXXXX 


1 do not anticipate the constructor will take any parameters. 


~coim_l Direct TmckXXXX 


If thoio la un uellvo connection lu tho cunloi tho connect will bo 
shut down when the destructor is callect. 






Connect() 


This method will force a connection to the carrier. 


GetPackageTrackingParamete 
rs() 


This method will be used to get a collection of parameters that are 
required to track a package. 

Parameters: 

An IMap interface that will be filled in with the parameters that are 
required to track the package. 


TrackPackage() 


The method will do the direct tracking of the package with the 

carrier 

IsClJ 1 lei . 

Parameters: 

An IMap interface that contains that parameters that are required to 
track the package. 

A pointer to an IStream interface that will be filled in with the raw 
tracking data returned from the carrier. 


Disconnect) 


This method will disconnect from the carrier. 






None are required. 






Sr/f ;" := ^;?=-. 7i;> ' : ■ -r^;^^ 

'-i ,-.4JP,V. • : \ ' - - . r i'>:"H.-i ■ - "-'^ - 1 " ^I'-i* XfaT-* ■-:>■, . ---v': 


None are required. 





Table 9.3.6-7. connJTDirectTrackXXXX Interface Description. 
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Interface connJTWebTrack 

This is the class that will implement the connJWebTrack interface. Unlike the direct track class 
there will only be a single class that will implement the WEB tracking interface. The reason that * 
there will only be one class to implement the WEB tracking interface is that WEB tracking is 
basically the same for all carriers. The only difference between web tracking for the carriers will 
be the URL that is used to track and the required parameters, and those can easily be data driven 
and be implemented by the same class. 







conn_TWebTrack() 


1 do not anticipate the constructor will take any parameters. 


~conn_TWebTrack() 


Any TCP/IP connect will be cleaned up in the destructor. 






Connect() 


This method is used to initial the TCP/IP connection to the carrier. 


Disconnect) 


This method will free up any resource that are being used for the 
TCP/IP connect. 


GetPackageTrackingParamete 
rs() 


This method will be used to get a collection of parameters that are 
required to track a package. 

Parameters: 

An enumerated constant that represents that carrier that the 
package will be tracked through. 

An IMap interface that will be filled in with the parameters that are 
require a io iractv ine package 


TrackPackageQ 


This is the method that will hit a carrier's WEB site to track a 
package. 

Parameters: 

An enumerated constant that represents the carrier that the 
package will be tracked through. 

An IMap interface that contains all of the parameters that are 
required to track a package. 

An (Stream interface that will be filled with th raw HTML returned 
from the carrier WEB site when the package is tracked. 
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None are required. 








None are required. 





Table 9.3.6-8. connJWebTrack Interface Description. 
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9.3.6.4.2 Class Diagrams 



conn TCarrierConnect 



CDconn_TCarrierConnect( ) 
2)GetRegistrationParameters( 
£3Register( ) 

£3GetWebTrackingObject( ) 
(!^jGetDirectTrackingObject( ) 
£3GetManifestParameters( ) 
QSendManifest( ) 



connJTTracking 



£jconn_Tracking( ) 
£3Connect( ) 
(2lDisconnect( ) 
£3GetTrackingParameters( 
QTrackPackage( ) 




conn TDirectTrac^UPS 



conn TDirectTrackFedEx 



conn TWebTrack 



Figure 9.3.6-2. Class Hierarchy Diagram for Carrier Connectivity. 

9.3.6.4.3 Free Function 

None are required. 

9.3.6.4.4 Interaction Diagrams 
None are required. 



9.3.6.5 External Dependencies 

The table below lists dependencies that this package has on other components and database 
tables. 



mmmmmmm 




f|j|j|||j| 




COM Object 


(Dictionary 


Microsoft dictionary 


DLL 


MFC42.DLL 


Microsoft MFC support DLL 


Static Library 


ATL . 


Active X Template Library > 


DLL 


UPSLINK.DLL 


UPS communications DLL 



Table 9.3.6-9. Carrier Connectivity Services External Dependencies 



9.3.6.6 Requirements Traceability Matrix 

The table below traces requirements from the Server functional requirements to components of 
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the Carrier Connectivity service. 



Table 9.3.6-10. Carrier Connectivity Services Requirements Traceabijity Matrix 
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EXHIBIT "J" 



Sent: 
To: 

Subject: 



From: 



Jinyue Liu [IMCEAEX-_O=VELLEB+2C+20INC+ 
2E_OU=VELLEB_CN=RECIPIENTS„CN=JINYUE@iship.com] 
Thursday, January 22, 1998 2:33 PM 
Movelt! Devel 

Notes on optional tag of enum in IDL 



Place the optional tag name of enum defined in an IDL in front of the definition {...} so 

that this tag name will appear in the TLH file when you #import the TLB generated by this IDL. 

for example, 

typedef [v1_enum] enum EConnectType {dbs_kShipping, dbs_kTracking, dbs_kReport, dbs_kAccount } EConnectType; 
when #imporfed, will generates 
enum EConnectType 

dbskShipping = 0, 
dbs_k I racking = 1 ( 
dbs_kReport = 2, 
dbs_kAccount = 3 

}; 

in the TLH file. 
But 

typedef [v1_enum] enum {dbs_kShipping, dbs_kTracking, dbs_kReport, dbs_kAccount } EConnectType; 
generates 

enum_MIDL MIDLjtf_Database_0000_0001 

f 

dbs_kShipping = 0, 
dbs_kTracking = 1 , 
dbs_kReport = 2, 
dbs_kAccount = 3 

}; 

Following typedef without trailing tag will not compile. 

typedef [v1_enum] enum EConnectType {dbs_kShipping t dbs_kTracking, dbs_kReport, dbs_kAccount } ; 



-Jinyue 



Sent: 
To: 

Subject: 



From: 



Paul McLaughlin [IMCEAEX-_O=VELLEB+2C+20INC+ 
2E_OU=VELLEB - _CN=RECIPIENTS_CN=PAULM@iship.com] 
Tuesday, March 24, 1998 8:06 PM 
Movelt! Devel 
Shipping Station Setup 




Shipping Station 
Setup.doc 



You now have two choices to when you want to use a shipping station: 



1. Choose either the shipping station in the main conference room or the one in William's old office on the device rack on 
the bottom shelf on the left. 

2. Put yourself through a little hell and setup your own PC as a shipping station and print labels on the shipping station in 
William's old office remotely. You don't need a scale. 

You will have to follow this document to get option (2) to work: 

«Shipping Station Setup.doc» 

With either option, you should logon to NT using the following user information: 
USER: sstation 
Password: hamsandwich 
Domain: moveit! 



-LowRider 



To setup a shipping station, do the following: 



UPDATE NT: 

• You must be running NT 4.0 with SP3. 
UPDATE IE: 

1 . The Shipping Station requires IE 4.0. 

2. Install IE 4.01 for NT. (This is on \\macarthur\scratch). 

3. Close IE. 

4. Logoff NT. 

5. Logon NT as "sstation" with password "hamsandwich". 

6. After IE gets done updating your system, right-click IE on the desktop. 

7. Select Properties. 

8. Choose the Security dialog tab. 

9. Select "Local intranet zone" 

10. Click the "Low" radio button. 

1 1 . Choose the Advanced dialog tab 
Under the "Browsing" category 

Turn off, "Show welcome message each time I log on" 
Turn on, "Launch browser in full screen window" 

12. Press OK to close the Properties dialog. 

UPDATE CLIENT FILES: 

1 . Copy all the files from "N:\PAULM\SHIPPINGSTATION" to a local directory of your choice (using your 
Windows directory is an example). 

2. "CD" into the directory you chose in the previous step, and type "SSSetup". 

UPDATE MONITOR RESOLUTION: 

• Set your screen resolution to 800x600, if you want the end-user viewing experience. 
CONFIGURE PRINTERS: 

• Setup a network printer driver to print to "\\QA2\Eltron 2044" by using the Add Printer wizard in 
Start/Settings/Printers. You may have to type in the net address of the printer to get the connection. 

MISCELLANEOUS FINAL IE SETTINGS: 

1. Launch IE. 

2. The shipping station URL is "http://gambit/ShippingNetwork/ShippingStation". Either make this URL 
your IE startup page, or save a link to it in your Favorites. Make sure that the URL doesn't point to the 
Setup subdirectory of ShippingStation if you save it as your home page. 

3. When IE launches, there may be an IE toolbar on the top. If so, right-click the toolbar and choose 
"Autohide". 

4. If you chose 800x600 resolution, turn on "Autohide" in Start/Settings/Taskbar. IE should be truly "full 
screen" after doing so. 



SETUP THE SHIPPING STATION APPLICATION 

1 . Tab to "Drop Off ID" and type "Movelt! Headquarters". 

2. Tab to "Password" and type "Battlezone" (yes, case sensitive). 

3. Tab to "Shipping Station Nam " and type whatever your heart desires. 

4. Click the Submit button. 

5. The Setup Control page doesn't work right now, so after it loads, press the "Goto Clerk Logon" button. 

6. Logon as your email name for the Clerk ID (e.g. I logon as "paulm") and your password is initially 
"password". 

7. Click Configuration 

8. Click Printers 

9. Choose "Eltron 2044" for the Label and Receipt printers. 

10. Select the driver attached to "\\qa2\eltron 2044" for the "local driver settings for the label and 
receipt printers. 

1 1 . You may leave the Report printer settings "not configured" for now as EOD isn't implemented yet. 

12. Choose "Manual Override" from the list of Supported Scales. You may leave "Local Port" as is. 

13. Click the "Submit New Configuration" button. 

14. Click the Logoff button and you're ready to ship packages! 

Come see me if you have any problems. 
-Paul McLaughlin 



Fr m: William Smith [IMCEAEX-_O=VELLEB+2C+20INC+ 

2E„OU=VELLEB_CN=RECIPIENTS_CN=WILLIAM@iship.com] 
Sent: Saturday, September 19, 1998 1:35 PM 

To: Shaindell Goldhaber; David Bennett; Chad Mentzer 

Cc: John Dietz 

Subject: RE: Proposed menus 



An implementation for voiding a package if you are not logged in: 
An edit field where you type the iShip tracking number 
press a button and it retrieves the least amount of info, for the 
user to verify that the package is the one they shipped. At this 
point you can void it or reprint the label. 

Problems I see: 

People messing with are system and trying to guess 
tracking numbers and voiding packages or reprinting 
another person's labels. 

The other implementation is to have the person send us 
an email if they want to void a package or reprint a label. 
We send them an email that gives them a special number 
they enter that only works with that package. We can 
check the sender's e-mail against the e-mail address of 
the person who shipped the package. 

W. 

> — Original Message — 

> From: Shaindell Goldhaber 

> Sent: Friday, September 18, 1998 5:26 PM 

> To: William Smith; David Bennett; Chad Mentzer 

> Subject: Proposed menus 
> 

> David doesn't like the idea of including left-hand menu buttons for section start pages. However, I've included them here 
for the sake of discussion. Also, I've added Reprint Label and Void a Package to the shipping menus. I'm not sure what 
the implementation would look like for users who are not logged on, however. 



> -Shaindell 
> 

> 

> Logged Off 
> 

> Home 

> Log on 

> Welcome 

> Sign up 

> Help 

> 

> Shipping 

> Log on 

> Ship a Package 

> Reprint Label (?) 

> Void Package (?) 

> Compare Services 

> Drop off Locator 

> Help 
> 

> Tracking 

> Log on 



Track a Package 
File a Claim 
Help 



Support 

Log On 
Contact Us 
Feedback 
How To 
Help 

Logged On 
Home 

Log off 
Welcome 

Address Book 
Preferences> ...> 
Help 

Shipping 

Log off 

Ship a Package 
Reprint a Label 
Void a Package 
Compare Services 
Drop off Locator 
Help 

Tracking 

Log off 

Track a Package 
View Shipping Log 
File a Claim 
Help 

Support 

Log Off 
Contact Us 
Feedback 
How To 
Help 



From: William Smith [IMCEAEX-_O=VELLEB+2C+20INC+ 

2E_OU=VELLEB - CN=RECIPIENTS_CN=WILLIAM@iship.com] 
Sent: Wednesday, September 09, 1 998 5:44 PM 

To: Chad Mentzer 

Cc: The Teamsters; The Raiders; The Wolverines 

Subject: Configuration Interface Design. 



This design can be reused for all objects that need configurations 
tied to an OID. Use Gary's config services otherwise. 
Paul M - 1 believe the CONFIGURATION database table is 
not being used. It should be removed in favor of either using 
Gary's config items or a special configuration tabel modeled 
after what Chad is doing. 

CHAD: 

Have something like this returned for a Configure() method on the acctJAccount and acctJUser interface. 

There would not be a COCLASS exposed. It is modeled after dbsJConfigServices. Steal the code. 

Default values for new accounts at time of registration should reside in Gary's config services. 

Don't store config. values that need have database rules enforced * 

(for example cascade delete). Add columns to your account and accountuser db tables 

in these cases. 

Add this method to acctJUser & acctJAccount 

HRESULT Configuration([out, retval] acctJConfiguration** pplConfiguration); 



Define this interface in your IDL 
acctJConfiguration 



object, 

uuid(3CAE1 31 8-A1 7A-1 1 D1 -9636-00A02475D4D9), 
dual, 

helpstring("acctJConfiguration Interface"), 
pointer_default(unique) 

interface acctJConfiguration : IDispatch 
[ 

propget, 
id(1), 

helpstring("property Item") 

HRESULT ltem([in] BSTR Scope, [in] BSTR ItemName, [in, optional] VARIANT GetDefaultPutDescription, 
[out, retval] VARIANT *pVal); 
[ 

propput, 
id(1), 

helpstringfproperty Item") 

HRESULT ltem([in] BSTR Scope, [in] BSTR ItemName, [in, optional] VARIANT GetDefaultPutDescription, 
[in] VARIANT newVal); 

id(2), 

helpstring("method Delete") 



l 



HRESULT Delete([in] BSTR Scope, [in] BSTR ItemName); 
id(3), 

helpstring( M method Exist") 
HRESULT Exist([in] BSTR Scope, [in] BSTR ItemName, [out, retval] int *pExists); 
id(4), 

helpstringfmethod Items") 
HRESULT ltems([in] BSTR Scope, [in] utilJMap *ltemMap); 

}; 



The ltems() method takes a map filled with keys (itemnames) that you want retrieved. 
After the call, the key values are filled in. This is for speed of getting multiple 
items (preferences). 

Scope would be for example: 
"DOCUMENTS" 

Item 

"ShippingLabelDevice" 

Value 

"\\macarthur\hp5msix" 
Description (optional) 

"Default label printer" 



TWO(2) database tables need to be created. 

ACCOUNTCONFIG 
and 

ACCOUNTUSERCONFIG 
These should have the 

sam design as the CONFIGITEMS table with the exeption that 

keys have to be added (unique key is the composite of the asteriks items): 

For ACCOUNTCONFIG 

ACCOUNTNO (VARCHAR 6) 

SCOPE (VARCHAR 38) 

ITEM (VARCHAR 255) 

VALUE (VARCHAR 255) 

DESCRIPTION (VARCHAR 255) 

For ACCOUNTUSERCONFIG 

USERID (VARCHAR 35) 

ACCOUNTNO (VARCHAR 6) 
SCOPE (VARCHAR 38) 

ITEM (VARCHAR 255) 

VALUE (VARCHAR 255) 

DESCRIPTION (VARCHAR 255) 

Cascade delete should be enforced if the account or accountuser is 
deleted as appropriate. Having configuration items is OPTIONAL. 



William Smith 
VP. Engineering 

iShip.com, Inc - The Internet Package Shipper 
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From: Paul McLaughlin [IMCEAEX-_O=VELLEB+2C+20INC+ 

2E„OU=VELLEB_CN=RECIPIENTS_CN=PAULM@iship.com] 
Sent: Monday, November 30, 1 998 3:20 PM 

To: William Smith; Chad Mentzer; Talal Karkutly 

Subject: RE: Columns to add to the portal table. 



I need to know exactly, given a SiteOID, how to get the associated Carrier Account. 

Currently, I go through the following path in many of my stored procedures to resolve a SiteOID to a CarrierAccount: 
SiteAndCarrier -> Account -> AccountAndCarrierAcnt -> CarrierAccount 

This works, because the SiteOID is only in the Account table once when the AccountTypeName is either "SiteAccount" or 
"ParentAccount". After the removal of SiteOID from Account I do not see how I can accomplish the Carrier Account 
resolution. I can't use AccountAndSite, because that table does not resolve to one Account. 

It is almost like we need a SiteAndCarrierAccount table? 

-LowRider 

> — Original Message — 

> From:William Smith 

> Sent: Monday, November 30, 1 998 1 1 :49 AM 

> To: Paul McLaughlin; Chad Mentzer; Talal Karkutly 

> Subject: RE: Columns to add to the portal table. 
> 

> Yes, I know that was its original intent, 

> but w/o it we can't share accounts across sites. 

> Comments? 
> 

> W. 
> 

> — Original Message 

> From: Paul McLaughlin 

> Sent: Monday, November 30, 1998 11:47 AM 

> To: William Smith; Chad Mentzer; Talal Karkutly 

> Subject: RE: Columns to add to the portal table. 
> 

> Remember, this was supposed to an exclusion table. I don't see how it can fulfill the role. 
> 

> -LowRider 
> 

> — Original Message — 

> From:William Smith 

> Sent: Monday, November 30, 1998 11:40 AM 

> To: Paul McLaughlin; Chad Mentzer; Talal Karkutly 

> Subject: RE: Columns to add to the portal table. 
> 

> There is a table called ACCOUNTANDSITE that should 

> fulfill this role. 
> 

> W. 
> 

> — Original Message 

> From: Paul McLaughlin 

> Sent: Monday, November 30, 1 998 1 1 :34 AM 

> To: Chad Mentzer; William Smith; Talal Karkutly 

> Subject: RE: Columns to add t the portal table. 
> 



1 



If SiteOID is removed from ACCOUNT, then there is no way to d termine what carrier accounts belong to a site. 

Removing SiteOID from ACCOUNT is going to break EOD, the DOL, and probably rating. 

-LowRider 

— Original Message--— 
From: Chad Mentzer 

Sent: Monday, November 30, 1 998 1 1 :20 AM 
To: William Smith; Talal Karkutly 
Cc: Paul McLaughlin 

Subject: RE: Columns to add to the portal table. 

You are correct. Both the SiteOID and Announcements Flag should be removed. 



Chad Mentzer 
iShip.com 

The Internet Package Shipper> (tm)> 
Phone: (425) 602-5032 
Fax: (425) 602-5025 
e-mail: chad@iship.com 

compare shipping with iShip.com at http://www.business.msn.com 



— Original Message — 
From: William Smith 

Sent: Saturday, November 28, 1998 12:54 PM 
To: Talal Karkutly 
Cc: Paul McLaughlin; Chad Mentzer 
Subject: Columns to add to the portal table. 

PARENTNO varchar(6) - The parent account number for all new user or site accounts added through this portal. 

ACCOUNTPREFIX varchar(3) - The prefix to append before all accounts created via this portal 

DOMAIN varchar(35) - The security domain under which all new users should be created and logged in under. 

In looking over the ACCOUNT table, it looks like 
SiteOID 

should be removed. An account doesn't have a site. If we want to have 
an account template for new account users that may have a default site, 
then that should be handled using a special accountuser record to act as a 
template. Chad/PaulM any comments? 

In the ACCOUNTUSER table, the announcements flag should be removed since it 
now exists in the ACCOUNTUSERCONFIG table. Chad/PaulM any comments? 



William Smith 
V.P. Engineering 

iShip.com, Inc - The Internet Package Shipper 



Sent: 
To: 

Subject: 



From: 



iship [IMCEAEX-_O=VELLEB+2C+20INC+ 
2E_OU=VELLEB_CN=RECIPIENTS_CN=ISHIP@iship.com] 
Tuesday, December 01 , 1998 6:44 PM 
William Smith 

Your Shipping Request # M AZHDY6 DYF2C0 



At 3:44 PM on Tuesday, December 1 , 1998 you shipped a package 
with iShip Package Number M AZHDY6 DYF2C0 via Next Day Air Saver, 
to Carl Lewis located in SEATTLE, WA. 

You must drop off your package before 5:00 PM on 

Tuesday, December 1 , 1998 in order for your package to arrive 

at its destination by Wednesday, December 2, 1998. 

Your selected Drop-Off location is: 

UPS Drop Box 
bellevue, WA 98005 



Your package weight is 10.00 lbs. 
The billable weight is 10.00 lbs. 
The charge for this package is: 

Base Service Charge: 



To check on the Status of the Package, go to: 
http://TESTNOC/ShippingNetwork/trk.asp?T=MAZHDY6DYF2C0 

To view any confidential information about the Request/Package you must, 
however, go to http://TESTNOC and Log On to your account. 

Thank you for shipping with iShip.com! 



$18.75 



Total: 



$18.75 
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Sent: 
T : 

Subject: 



Fr m: 



Paul McLaughlin [IMCEAEX-__O=VELLEB+2C+20INC+ 
2E_OU=VELLEB_CN=RECIPIENTS_CN=PAULM@iship.com] 
Tuesday, July 20, 1999 5:20 PM 
iShip Devel 

Some very interesting ActiveX/IIS issues have been solved 



Ordinarily, this might have been a day or two road block, but since Mark, Reichie and I pulled together for about a half an 
hour, {voice:select("Hanz and Franz")} "We crushed those girly man bugs like the puny insects they are. Ya!" {voice:select 
("default")} iShip.com rocks! 

Problem 1 : ActiveX controls refused to download even though client system was clean. 

Solution: The virtual directory "bin" (that points to your equivalent of $/WebApps/bin), had in IIS the "Execute" permission 
set for the directory, when it should have been only "Script". 

Problem 2: CSZ Database ActiveX control installed correctly, but CMS still thought it had not. 

Solution: As far as COM was concerned, it did install correctly. All the files where registered and on the clients system. 
However, the Z5PLUS.TXT needs to be in the same directory as the MSI_ShippingStation.dll and my JScript calls a COM 
function in the dll to check this. It was this call that was failing for some reason. 

So why then was the ActiveX control installing correctly for COM, but the Z5PLUS.TXT file was not in the "downloaded 
program files" directory when viewed from a command prompt? Well, turns out that when the ActiveX Component 
Download process checks to see if a file already exists, it doesn't just check the target directory of the file (specified in the 
.INF file), but rather it does the standard "search for file" process as defined by the Win32 API function SearchPath(). This 
algorithm searches several different locations, the last of which is the PATH, and guess what file was coincidentally found 
along the PATH? Yep, Z5PLUS.TXT was in the "...\debug\bin" directory which was in the path (as it is for most of us 
developers). So, we nuked the Z5PLUS.TXT file from "debug\bin", tried the CMS install again and everything worked fine. 

I am going to check to see if my use of the default destination directory causes the search to happen, or if I tell it explicitly 
to use the "downloaded program files" directory that it will not search for the file in the aforementioned manner. I'll let you 
know. 

Learn something new every day. 

Paul R. McLaughlin 
iShip.com 

Your. Internet Package Shipper (tm) 
Senior Software Developer 
(425)602-5046 (work) 
(425)602-5025 (fax) 
(425)556-9257 (home) 
(425)444-9257 (cell) 
e-mail: paulm@iship.com 
http://www.iship.com 

compare shipping with iShip.com at http://www.business.msn.com/shipping/compare.asp 



Sent: 

To: 

Cc: 



Subject: 



From: 



Paul McLaughlin [IMCEAEX-_O=VELLEB+2C+20INC+ 
2E^OU=VELLEB_CN=RECIPIENTS_CN=PAULM@iship.com] 
Wednesday; auly;2^1.1999^:5^PMr^ 
William Smith; iShip Devel 
Ken Sinclair 

RE: Caching Data On The CMS Client: 



Importance: 



High 



Here is how it will be done. I will use the Sitelnformation dialog as an example throughout: 
Overview: 

1 . The developer in charge of data that needs to be cached on the client, will develop a global JScript object exposing the 
data as properties and will be contained in the cmsApps.asp client-side script. 

2. Ul that presents this data, for example the Site Information dialog, will continue to use the tx file they have to get the 
data, however, the tx file will update the global object (via the object's exposed Update() method) and then the dialog will 
instead update its Ul with the property values from the object. 

3. Client-side script that cares about such data will always get it from the global objects. 

4. I will write a server and client-side "command processor" that continuously polls our servers for new commands to run, 
one of which can be "submit a tx file". This will be the exact same be file that the dialogs use to get the latest data. The 
client-side command interpreter will then also call the global object's Update() method exactly as in item (2). 

Note that the development of the global objects and their integration with the dialogs are not effected by my development 
of the command interpreters. The dialogs and global objects should be completely unaware of any existence of my 
command interpreters. 

TODO: Detailed Development Tasks 
Stuff you need to do: 

1a. If you have data that needs to be cached, then you need to create a new "js" file that contains an object named after 
your Ul component (like William recommends below). The .js file should also be named after the object name. 
1b. The JScript object will expose a property for each data element that is cached. For example, gSitelnformation.City 
and gSitelnformation.State would return the respective data items. 

1c. The JScript object will support a member function called Update() which takes the exact same object that is returned 
by the tx file when it calls its equivalent of "parent.txComplete(txResult)". 

1d. All JScript functions in the JS file will be prefixed with a unique prefix that is named after the object. This is necessary 
because many js files will be included in a single page and we must avoid name conflicts. For example, the JScript 
function for the object's Update function property might be prototyped as "function siJJpdate(txResutt)" and then of course 
. later on it would be assigned to the Update property in the constructor of the Sitelnformation object as "this.Update = 
siJJpdate;". 

2a. cmsApps.asp will be the container for all the cached data. 

2b. cmsApps.asp will be modified with "<script language="jscript" src="yourobject.js"></script> n for each object that is 
needed. 

3a. Your Ul components current have some sort of M txGet....asp n to retrieve the data. This file will stay the same with one 
exception: you must rename the "parent.txCompleteftxResult);" line of script to be something unique named after your 
data set. For example: "parent.txCompleteSitelnformation(txResult);" 

3b. Move and modify the code of M bcCompleteSitelnformation(txResult)" that updates the Ul from the txResult object, to a 
separate function. In that function, instead of getting your data from the txResult object, you must get the data from the 
properties of the global cached object. 

3b. Modify the code of M txCompleteSitelnformation(txResult) M from updating the Ul directly, to merely passing the exact 
same txResult object returned from your tx file, to the cached object's Update() function. 

4. All client side script that cares about this cached data, needs to get the data from the appropriate global objects. 

Stuff I need to do: (none of which effects your development, but just FY!) 

1 . Complete command table design and add schema to database. 

2. Add data to command tables to facilitate running tx files. 

3. Write server-side command processor tx file. 



1 



4. Write client-side command interpreter. 



NOTE: Until my command interpreter thing works, the object will NOT CONTAIN any data until you open and close the 
corresponding Ul component. In other words, you must open and close the Site Information dialog to "refresh" the data 
the Sitelnformation global object. 

EXAMPLES: 

Sitelnformation.js: 

function si_Update(txResult) 

{ 

// update all data properties with returned tx data. 
this.City = ...["city"]; 

} 

function siJnitProps() 
this.City = ,w ; 



function gSitelnformation() 

this.Update = siJJpdate; 
siJnitProps(); 



gSitelnformation = new gSitelnformation(); 
cmsApps.asp: 

<script language-'JScript" src=7cms/lib/Sitelnformation.js"></script> 

txGetSiteinformation.asp: 

parent.bcCompleteSitelnformation(txResult); 

The Sitelnformation dialog: 

function UpdateUI(oSI) 
f 

document.frmSl.editCity. value = oSI.City; // substitute with your objects of course. 



function txCompleteSitelnformation(txResult); 

* var oSI = dialogArguments.cmsAppsWndPtr.gSitelnformation; // or however you pass it into your dialog. 
oSKUpdate(txResult); 
UpdateUI(oSI); 

hope this helps. Don't hesitate to ask any questions or send comments my way. They will be appropriately filed. ;-) 
-LowRider 

> — Original Message — 

> From: William Smith 

> Sent: Tuesday, July 20, 1999 8:58 AM 

> To: iShip Devel 

> Cc: Ken Sinclair 

> Subject: Caching Data On The CMS Client: 
> 

> This is HIGH priority. 



> If you worked on the Preferences, Center Information or Scales and Printers dialogs in 

> CMS, you must ASAP provide a JavaScript object that exposes the current settings to the 

> client side code. Shipping needs access to this information. There is a CMS app area 

> that can be used to cache this data globally. Obviously it must remain in sync with changes 

> made via the dialogs. One way is to have properties on this object that expose the current values 

> and methods that do the transactions. Please send out to the development with sample code, 

> how to access the current values on the client side. I would anticipate that a Preferences, 

> ScalesPrinters and a Sitelnformation object or some other name would exist. 
> 

> Notice I used Sitelnformation NOT Centerlnformation. Please think about the fact 

> that the code you are creating today will be used in places other than MBE. 
> 

> Sean Hu has done this very well by creating a JavaScript object for the Hardware settings. 

> Sean please work with Reichie and MarkB (if they are the right ones). 
> 

> PaulM - The COMMAND function you are working on, should have a way to 

> refresh these objects on the client side if a change is made on the backend 

> using the Administration system. 
> 

> 

> William Smith 

> V.P. Engineering 

> iShip.com, Inc - Your Internet Package Shipper 
> 

> 
> 
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From: Jinyue Liu [IMCEAEX-_O=VELLEB+2C+20INC+ 

2E_OU=VELLEB_CN=RECIPIENTS„CN=JINYUE@iship.com] 
Sent: Monday, July 26, 1 999 2:50 PM 

To: Glenn Crowe 

Cc: William Smith 

Subject: RE: MBE Customer ID Requirement. 



The input will be custom id (an integer) and the output will be the check digit. 

function Mod10(int CustomerlD) 
{ 

intOdd =0; 
int Even = 0; 
int i = 0; 

while (CustomerlD > 0) 
I 

' int Val = CustomerlD % 10; 

CustomerlD = CustomerlD / 10; 

// Separately add up the number in the odd and 
// even positions of the input string. 

if ((i+1)%2) 

Odd +=Val; 

else 

Even += Val; 

i = i + 1 

} 

// Add the sum of the odd position characters 

// to twice the sum of the even position characters. 

// Then get the remainder of this sum. 

int CheckDigit = (Odd + (2 * Even)) % 10; 

// The check digit is 0 if the remainder is 0. 

// Otherwise, the check digit is 10 - the remainder. 

if (CheckDigit > 0) 

return '0' + (10 - CheckDigit); 

else 

return '0'; 

} 



> — Original Message — 

> From: Glenn Crowe 

> Sent: Friday, July 23, 1999 3:02 PM 

> To: Jinyue Liu 

> Subject: FW: MBE Customer ID Requirement. 
> 

> Jinyue, 
> 

> This is the algorithm that William wants me to implement. 
> 
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> Thanks! 

> 

> Glenn Crowe 

> Associate Developer 

> iShip.com 

> Your Internet Package Shipper (tm) 

> glennc@iShip.com 

> 425.602.5044 
> 

> Check us out at http://iShip.com. 
> 

> 

> — Original Message — 

> From: William Smith 

> Sent: Friday, July 23, 1999 2:56 PM 

> To: David Bennett 

> Cc: Glenn Crowe 

> Subject: MBE Customer ID Requirement. 

> 

> The customer id will be a 1 5 character field with the following format: 
> 

> Mcmmtmmmm 
> 

> The human readable format shall be: 

> \ 

> MCMS-# ## - ffff#tf ftftffff it 
> 

> The prefix "MCMS" stands for MBE Counter Manifest System 
> 

> The middle 10 digits are 0 padded integer starting at 1. 

> Each newly generated Customer # will be a simple increment 

> to the last number assigned customer number. 

> The human readable portion of this number is hyphenated just 

> like a phone number that includes the area code. 
> 

> The final digit is a MOD 10 (UPS Algorithm) of the 10 digit number 

> portion of the customer id. The Check digit does not include the 

> "MCMS" prefix. 
> 

> In all cases where the customer id to read in the CMS, EPSO applications or 

> on a report, the human readable version shall be display. 
> 

> In all cases where a customer id can be entered into the system, the data 

> entry field shall support both the human readable version and the raw 

> customer id. Data entry shall except either hyphens or spaces the 

> delimit fields. 
> 

> Implementation notes: 

> The current value of the MBE customer id will be stored in the _AccountConfig database 

> table associated with the MBE master iShip Accounts 
> 

> The stored procedure that retrieves the next available customer id shall take an iShip Account* as 

> input. This account* shall be used to locate the AccountConfig item. If this item does not exist, 

> it shall be created, and a customer id with the number portion set to "1" shall be returned. 
> 

> The stored procedure shall return a complete customer id in non-human readable format as a string. 
> 

> The stored procedure must make sure the deadlocks cannot occur and the transaction is atomic. 
> 

> The account config item shall be named: 

> MBE.CUSTOMERID.CURRENT 
> 

> William Smith 

> V.P. Engineering 

2 



iShip.com, Inc - Your Internet Package Shipper 



